# AI's Impact on Engineering Teams & Strategy

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-08-07

## 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.
This is Shane Hastie, and we're here for the InfoQ Culture and Methods Trends Report.
And I have a plethora of wisdom on the screen in front of me today.
So I'm going to just do a whip around my screen and ask people to introduce themselves because we have quite a group here today.
Vanessa, can we start with you?
Good morning, everybody.
I'm Beres of Mikola.
I'm an engineering leader, a social technical architect.
It means I work on both technical leadership sides.
And in general, I try and fix problems in the system.
And moving around, I've got Ben Linders.
Ben.
And Eugene.
Ben Linders, one person company, mostly focused on the social aspects of social technical, team collaboration, people, safety.
And reflection learning, that's the kind of stuff that I'm focused on.
And Philip.
Hey everyone, my name is Philip Mortimer.
I'm a machine learning engineer specializing in document intelligence.
My background is mostly in finance.
I used to work for a bank and most recently in fintech.
Yinka.
Hey everyone, my name is Yinka.
I'm a software engineer.
I also have a background in finance, so I used to work at.
At a bank, currently at an HR tech company, mostly workers in IC nowadays.
And Raf?
Raf Gamal, based in New Zealand.
I have been in the industry since, well, I've been cutting code since about the 80s.
I'm a senior director at Amartek.
I'm very focused on helping engineering teams collaborate, work together across borders, across time zones.
and deliver and learn through feedback loops.
And obviously, in this current day and age, this moment in time, embrace AI and become as AI-first as we can be.
Welcome.
Craig.
Hi, Shane.
Hi, everybody.
My name's Craig Smith from Australia.
Been around the culture and methods and agile community for 20, 25 years.
These days, I'm in the government context, helping teams deliver software as a delivery lead.
And Shauna, welcome.
Thank you so much for having me.
I'm Shana Martell.
I'm these days a principal engineer in the fintech space.
Spent a lot of my time thinking about how to really foster our staff plus engineers in our organizations.
Yeah, I'm Shane Hastie, the lead for all things culture and methods at InfoQ.
And my day job is educating people in the socio side of socio-technical systems and leadership development.
growing teams, growing people, and figuring out how we work most effectively as human systems in this socio-technical environment.
We've got a variety of topics we want to touch on, but the first one, and it's impossible to talk about teams and organizations without touching on AI today, so I'm going to do a quick round-robin and ask people, What is the biggest trend that you are seeing or thing that you would want our audience to consider when looking at the human aspects of software engineering today?
And Vanessa, I'll start with you.
Thanks, Jen.
Big topic here.
So I think one of the things I would like people to think about the most these days is...
With what level of maturity and to what extent they want to integrate AI.
I think we're all excited about it.
And it's nice that everybody's jumping on a wagon and trying to do as much as they can.
I think it's very important to start considering what are the risks and to what extent, what is appropriate in what circumstance, for which software, for which company and for which group of people, which is conversation we used to have in the past.
And I feel that these days is more everything or nothing in the AI space.
So how do we move away from that every single nothing?
It's more how do we apply the same reasoning that we've used in the past?
You know, what's the risk?
What's the impact?
What's the specific circumstances of level of maturity, let's call it, not necessarily the positive connotation in all cases, for each piece of software?
So there is easier pieces of software or less low risk pieces of software that would require more attention, more human in the loop, less human in the loop.
So there's a different degree.
And I feel that these days we are just saying, AI everywhere in everything, well, we should just understand how much would be a catalyst for improvement and how much wouldn't.
Cool.
So frameworks of maturity for AI acquisition, I would say.
Frameworks of maturity.
And jumping across, Ben, what are your thoughts?
What is the thing that people should be thinking about today?
I think the thing to think about is that collaboration patterns are changing in teams, between teams, between organizations.
And one key aspect that enables this kind of collaboration is psychological safety combined with transparency.
So how are people communicating with each other?
Do they feel safe enough to raise any issues that are there, any problems that they see, but also any opportunities that path by?
I think that's where the adoption of AI is having a great impact.
And I think it's also tied to the maturity, I would even say more capability.
The majority are people capable enough to work with AI, but still feel safe enough to work together and to raise any issues in there.
That's the kind of key aspect for me, how that is changing the way that teams work.
But haven't we been tackling psychological safety since at least 2014?
We've been tackling it a long time, and I've seen a lot of positive developments in the area of psychological safety.
I think it's got a dip with COVID, actually, because people went back to their security, to their personal security in there.
I think also with recent global developments in there, this is, again, challenging the aspect of psychological safety.
There's nothing we can change about that, but it's still making it an important topic.
We're not there yet.
Thank you.
Philip.
For me, maybe following on a little bit from what Ben said, I'm interested in how we handle the cognitive load of ultra-fast development.
We're all being pushed, perhaps many of us are being pushed, to adopt hypervelocity engineering, compound engineering.
We're working on multiple work streams at once.
You may have multiple agents running at once.
And it becomes really hard for us humans to keep up with that, manage that, manage the constant context switching.
And I think it's something that we need to work out.
How can we improve our processes to take advantage of this?
I think lots of development processes that we used to have as software developers, as engineers, don't really work anymore.
Like, for example, the pull request process.
Can you really read all the code that AI generates?
Yeah, one figure that we've had on the podcast was 300% more code, 400% more bugs going hand in hand.
Yes.
I saw recently that GitHub is going from, I think, 1 billion pull requests per year to something that expected 14 billion pull requests per year predicted for 2026 from 1 billion last year.
That's a 14x increase.
We need to build the systems that lets us manage and understand what we're building.
14 times the cognitive load.
We're already buckling under the pressure.
Raph.
What are you finding?
I think I'll echo what Eric has said to some extent in that Vanessa's point around value and, you know, remembering how we built software to date is still very relevant, but it's changing because we're moving faster.
We've got larger PRs.
But at the same time, I really try to emphasize that need to keep asking, what is the value we're delivering, right?
We can generate just about anything we think about right now.
And we push it across the line.
Is it having the return?
on investment that we expect it to.
We have huge spend on tokens, right?
So FinOps is still as important as it ever was, but are we getting the return that comes from it?
We're using models and capabilities that are very heavily subsidized by providers upstream.
Are we being cognizant of the fact that we're coupling ourselves with this huge investment that is heavily subsidized today?
You know, what is the plan forward?
So what I throw out there is that I think redefining engineering, we're kind of in that space at the moment.
And I don't know where it's going, but I'd remind people to be cognizant of the fact that there were a lot of methods that proceeded where we are today.
Harness engineering, for instance, is very much, in my mind, staffing analysis, plus, you know, other guardrails and whatnot.
But there are practices that we've had to date that are being rebranded.
And I think if you study what came before, it's a good grounding.
for how we can enable teams going forward.
Because for years, we've been trying to make sure that teams had high quality code, confidence in what they shipped, trying to deliver the right value to the right users.
And I don't think that's gone away.
I think that's perhaps more important than it ever was.
Jim Highsmith has said, if you failed at Agile, you will fail catastrophically at AI.
100%, I think.
And yet many of our organizations still haven't.
embedded the fundamental principles of agility in their ways of working.
And fast feedback loops.
I was going to throw out there, I see a lot of people trying to run and skipped some of those steps or you didn't really refine them.
And now, you know, to Philip's point, massive PRs, risk is bigger, chunk science is bigger.
How do we have confidence that we're pushing them out?
We got the right observability in place.
You know, we shifted right enough in that org.
I think there's a whole bunch of maturity people are trying to catch up with.
in order to get value from the models, from their agentic work.
Right.
Shane, you just touched on what I was going to say, which is, I think it's the gap between the good and the not so good and the haves and the have nots.
Some organizations have embraced this and ran with it, but there are many organizations, as you alluded to, they never really made the leap to agility practices in the 25 year span that we had in order to do that.
And now they're trying to adapt to these new practices and still building it on.
organizations that are still pretending that software is being built in 1995, the challenges are now becoming about how do we embed the human in the loop, but also how do we go at speed?
How do we deal with collaboration in this new world when an agent is the thing sitting next to you, to the pull requests?
How do we deal with quality?
Is the same machine that just built that, the same engine that is also testing, the same machine that is also now doing the DevOps that gets it out there?
So I think we've got some real challenges to face.
You know, this is a brave new world.
It's just the next step of our evolution in software development.
But unlike other advances that have come, I feel that this is just going at such a pace that we haven't built those things to keep up with it.
And the GitHub example was a really good example of that is we haven't built the practices that build behind this, both for people and for the technology.
And sure enough.
I think this is echoing what a lot of other folks have said, but the code is really easy now, much easier than it has been before.
Are we doing what we need to do to understand if we're actually solving the problems that we're setting out to solve for whoever our customers are?
Are we doing the measurements we need to do to say that these experiments are working?
That's something I saw a lot of organizations struggle with long before AI.
They shipped something, but they maybe never went back to actually understand if it solved the problem that they had.
What if we're now doing that at scale?
How do we understand if we're actually bringing value to our customers?
Yeah, when knowledge is a commodity and code is easy, how do we know what value actually is?
And are we keeping up as we ship more and more?
Are we keeping up with understanding if that shipping is actually making the lives of our customers better or not?
Harvard Business Review last year's word of the year was work slop, which is the work that we do generating AI content that makes things harder for people further down the value stream?
How much code slop are we producing?
Yinka?
Yeah, I think, according to a lot of what's been solved, for me, a quick summary is that the role of brain-tunnel is really changing.
And beyond, I guess, just typing out the code when, as I mentioned, code is easy, beyond...
just reviewing the code because now the chunk sizes are massive.
So the role is really, really evolving.
It almost feels like there is a lot more people are moving into platform engineering where now we're developing platforms for agents to be able to write the code and then possibly be able to review it more effectively and also let other colleagues contribute.
So it feels like we're becoming...
or engineers are becoming a lot more custodians rather than just contributors.
And we're seeing that evolution in real time.
And for me, it's particularly interesting.
And I'm also really curious about it because I don't know to what extent it's going to go.
I think some interesting stats have been a lot more people adopting AI usage, but fewer people are trusting the output, which is their really interesting contradiction or And I think as an engineer, our role would evolve a bit more into driving that first factor by building more systems, building more guardrails, building more things that make it all work together and drive proper business outputs.
Driving proper business outputs and outcomes.
Thank you all.
A great starting point for our conversations.
I'd like to dig into and get people's thoughts on What is happening to teams?
We used to talk about T-shaped skills, cross-functional teams, the two-pizza team.
What I'm seeing is that two-pizza team is becoming a one-pizza team.
You know, two people and an AI tool or a swarm of agents.
What's happening in the collaboration space there?
Who would like to tackle this one?
I'll give it a go if you want.
So clearly, as we have different problems and different companies, there would be different solutions for this.
But I think the big consideration that we need to have is how do we expect this system to evolve?
So when we look at the team, even before we used to think, OK, this team requires this skill set, this software will last, this software will be for the developer user, for the actual user paying a subscription.
We always had some metrics to say we need this kind of team for this kind of problem.
The conversations that we're having today are more who's going to evolve this software?
How many people?
What interaction do I need with that software going forward?
What skills do I need that are human in that software going forward?
So I can foresee models where maybe more business critical pieces, where you have what we've called a team up to now, but super powered by, you know, models, agents and supporting what they can.
And I can see lower risk teams where is actually product manager in one dev.
This can open roads to completely different setups of teams, you know, agents as team members in a group of humans, teams of agents for, I don't know, depending on the kind of risk.
The key question for me here is you need to know ahead of time what you're looking for, because building software for humans is different than writing software for machines.
The level, and I think my colleagues here were mentioning different aspects of this.
quality, return on investment, even whether we're actually delivering the right thing or how can we manage the cognitive overload of what we need to do is a variable that you need to have in your mind before you decide to not have that many people in the team or to hyper automate things to what extent.
This is a beautiful technology that we need to be able to manage and at least be honest on how we plan to manage it, at least for a period of time.
Otherwise, models of collaboration between teams and the organization or even your risk factors of hyper generating entire system that nobody knows how to do will backfire very quickly.
But such a beautiful technology can be used properly.
We just have to be a little bit more honest about what we aim to do with the team and with the company at this point in time, in my opinion.
Philip, you were going to say something.
Yeah.
I mean, Vanessa, you mentioned team could now be.
one product manager and one engineer.
But these days, the lines between different team members are becoming very, very blurred.
Mark Anderson has talked about this Mexican standoff between engineers and product and designers, where previously they all had a distinct role, but now designers can think about the product.
The product managers can write code.
So now we really just have this one class of people.
which he's calling just builders.
So we're all builders now.
And I see this in my own organization.
I see members of the product team and the design team committing code just as freely as engineers these days.
And really the engineers are there to provide perhaps the underlying primitives, the architectural designs, the APIs that will give everyone in the organization access to the underlying data.
I think that's a massive shift in the way that teams work.
Maybe to add to this, I think the whole idea of teams as the solution for people collaborating is changing.
It's not about the teams.
There are much more different ways these days to collaborate.
As you mentioned, it can be one-on-one.
It can be one person working with an AI agent and making a project in there.
It could be a whole organization based around model ideas working on that.
So the thing that we should be looking for is not We need to make teams.
The thing is, how can we make collaboration more effective in the organization?
That's where our focus should be.
That's a great thought.
It's gotten really interesting in terms of what makes up a team.
Particularly some other things I've seen is going back to the old article from some flight makers around the engineer manager pendulum.
A lot of managers swing back into being engineers.
writing code and actually delivering features.
It blurs the lines a lot, not just across different verticals like products, design and engineering, but even within engineering.
And then you're seeing probably previously roles that were very specific, like in a team, you could have a front-end, back-end of a structure platform, but it's blurred lines so much.
And I do think it's creating maybe even more this idea of...
one person team, smaller teams.
But to Ben's point, I'm also curious about how this technology can help us accelerate collaboration actually.
Because I think that's your sense of organization.
So how can it help us not just deliver more as individuals, but actually collaborate more.
I think one of the dangers of these like one person teams is it takes away some of the collaboration that we expect from our work.
Like part of the reason that we like to go to work is that we like the people that we work with.
And I can't imagine, maybe I'll regret these words.
I can't imagine feeling that way about an agent.
And I think that we want to understand how do we foster in our organizations, not just efficiency and making sure that we're shipping the right things, but also keeping the human aspect of just like part of the joy of work is getting to work with other people.
I can't resist.
June 2026, Harvard Business Review article, How People Are Actually Using AI Today.
The number one use, therapy and companionship.
Number nine, which worries me immensely, astrology and tarot readings.
Jane, I feel like you're telling me I'm going to regret my words in a month, which maybe I will.
Maybe I will.
Technical use of software, autonomous agent generation as numbers five and six, improving code and generating code.
Last year, 2025, they were number five and eight.
They're now 78 and 69.
That's not because we're doing less.
It's because more and more people are using these tools.
So a year ago, two years ago, the IT, the technology industry, we were the heaviest users.
We're not anymore.
But yeah.
Therapy and companionship is number one.
Craig, did you have any thoughts on this one?
Yeah, I hear all the thoughts that people have said.
We talked about the one-person team, and I think that's the thing, but what's also happening is when we were in this agile space, we would talk about these roles of product owners and scrum masters or technical leads or whatever you want to call it, and the roles in the team.
Those things are starting to disappear.
And Philip talked about this, that if that same person, those people are committing code or if those people are doing it, we're losing that crossover piece.
So you've got these one-person teams and it's a product owner going, I think I want to do what a product owner does.
And a manager might be committing code and a dev.
And we're not collaborating to find the best outcomes.
But what I'm also seeing is then the teams actually in organizations, they're still there.
But now it's like, well, we don't need these little small teams we had.
We can now have a team of 25, 30 people.
but they're all little one person inside a big team.
And when they do get to collaborate, even if they do turn up for the daily standup, because that's the thing that we do all now, they're all just talking about different things and hiding the fact that there is an agent helping them.
So now what we're getting is someone says, can you send me a document?
And now you get a 47 page document that you have to read, which, okay, we'll then use the AI to read that and give us a summary.
So we've got AI helping us with the AI and then AI is helping us with the AI again.
outcome.
So we've lost that art of the collaborative nature of building great software and teams as we all move towards this technology.
And I think that's a real shame.
How do we get that human back in the loop?
Use the tools for what they really give us the power to do, but figure out how we best fit into this rather than just sending that, as you called it, slot around the place within our teams.
It's a real concern.
Yeah, I think part of the magic of working in a team is having different viewpoints and different areas of expertise, bouncing ideas of each other, challenging each other.
And you're absolutely right.
You kind of lose that if your teams have degenerated into a bunch of one-person teams all working on completely independent projects.
Raph, you're leading some of these teams.
What are you seeing?
I can't talk about my specific context because rules, but I'm definitely seeing smaller teams, right?
And like, you know, to take an external example, someone was talking to me about a gig recently with a tax company.
that had tried to bibecode a rebuild of attack system.
And I think they got a few people who were less experienced and they built it from zero.
It failed.
And someone I know is potentially, you know, going to be involved as a more senior developer in that build.
And that takes me to a place of something that's been on my mind a fair bit, which is that once you open up these doors to say, hey, everyone can be T-shaped, right?
Getting T-shaped.
was never just like an easy journey.
It was a journey of like initiation and learning and failure and success.
So being able to cast your wand and have something working will not always give you the judgment, right, of being able to decide if this thing will scale, if this thing will be maintainable in two years.
Yes, our models are amazing at refactoring and they'll probably be so much better in two years.
But there is this thing in my mind around we're seeing a lot of output.
Again, back to that thing about value.
We're seeing a lot of output.
Is that output going to last?
Is it going to be sustainable?
Are there skills that we're not nurturing?
I saw a piece of this actually by Daniel, you know, thank you, Daniel.
And he reshared something from someone who was talking about how in the Vibe code world, you've got people who are senior leaders.
And I see a lot of this, a good senior with a tool is amazing, right?
Senior leaders.
Back on the tools.
I love it.
I'm building some VR stuff.
And someone recently reminded me, don't be arrogant about what you produce because you didn't really produce it.
But there are a lot of senior leaders building stuff.
And they're putting their effort into creating solutions with guardrails around it, with harnesses, perhaps using STD.
And they're really proud of it.
And they take a few other seniors on the journey.
And something was shared that they're kind of effectively coaching.
this machine that may have some memory, but it may not be the same as the plasticity of like, say a junior.
And that really got me thinking about the fact that you've got a lot of juniors out there who could be doing that supervisory work, who may have that plasticity to learn from mistakes.
You tell the model once when it fails, Hey, here's my guide role.
Don't do this again, right?
Like you were, you were logging this to the wrong system or you were using the wrong library.
You've said it in stone going forward.
But what it's not learned, as an engineer would, is actually consider your choice of libraries.
Consider whether or not this is consistent with the rest of the platform.
Yes, that's a really bad example because you can get past it.
Half the examples are really bad ones.
But that plasticity isn't there.
And so in my mind, there's this need to make sure we keep investing in juniors.
make sure we keep those seniors in a place where they're guiding and they're growing individuals.
We're all becoming rock stars, right?
And I've heard the term even used, and Tiger teams, all sorts of shit.
And it hurts me, but we're going back to that place where we knew for a long time the rock star wasn't the right thing.
As Philip said, we knew that diversity of thought in our teams was important, diversity of perspectives.
Instead, those perspectives have gone.
You've got the individual working with an agent that's Knowledge is built from the same corpus as every other person sitting next to them.
And that personal diversity is going to be lost in all of it.
So a bit of a ramble there, but I think there's a human element to this that we shouldn't lose.
I feel like the old guy now.
There's a question there about career paths.
How do we teach the junior engineer to become the senior engineer?
And is what they need to learn different today?
I think it is.
I will throw in a disclaimer there that I'm quite dubious as to whether or not we're going to get the same level of interest in junior engineering roles.
And one of my own children is looking at Elec Eng, who is a very good developer.
But the criteria for someone going into that role may not be what it was before.
It's like, as Philip said, we're getting PRs from left field.
There's a Steve Yege thing I've read recently, which was around the juniors being almost gatekeepers.
for work coming in from UXers, from product, to validate that those are hitting the bar of scalability or worthy of being integrated into the rest of our code base.
There are questions about, again, maybe more advanced concepts around, is this heading in the right direction for the product?
Is this something we can merge?
And you're becoming a gatekeeper at that stage.
In my mind...
is already a level above where a junior was sitting at because there's a journey you go through as you learn to ask those questions.
I remember when I started, all I wanted to do was cut out code and be in a meeting and smash something out.
And then you learn that you're trying to build the right thing.
There's a whole journey there.
You don't just start there.
So I don't know what people's thoughts are on the solution to that, but I think there's like a level of maturity you have to reach even to have that entry-level guardrail.
Philip?
I think right now, We're in this kind of weird state where if you're a senior and you have good judgment and you have good experience, AI is like this massive force multiplier and you can do incredible things.
If you're a junior, maybe you don't have the experience and the judgment, it's a force multiplier, but maybe not in the way that you want it to be.
But if we look ahead, maybe in six months to a year's time, when the models are even more capable than they are today, if you can imagine that.
Then I think really the only skill that will be important is how well can you use AI?
How well can you corral all of these agents working for you?
And then I think that's going to be a completely new skill.
And then I think we'll see the younger generation come through who have more mental plasticity, can pick up these new skills better.
And then they will start to run rings around old guys like me in a year's time.
I think that's coming, maybe not quite today, but in six months or a year's time, we'll be there.
I guess the thing I wonder about quite a bit, Philip, is yes, they will be very good with the tools, but engineers are very good with the tools.
The challenge is sometimes growing to the point where you're very good at asking the right questions.
You're very good, not in terms of like agentic questions, but about the product you're building, the problem you're solving, right?
What am I trying to solve here?
And that's, you know, depending on the individual, can take quite, it's a journey, right?
And it's lots of little micro realizations.
And getting straight there, maybe it's just a better agent that's taught to coach you in good sound product decisions.
But the individual, yeah.
I'm curious to see that, people go on that journey.
I think it's going to be very messy in the short term.
But I do think in the long term, the way engineers learn is going to be different.
I think for many of us, learning over many years was...
Like what we said about learning how to ask the right questions, learning fundamentals.
But a big chunk of it was also learning the implementation, like how to write good Java code or how to write good C code and things like that.
And that's not as necessary anymore.
So it frees up a bunch of like a mental bandwidth to then focus on, you know, the things you mentioned, like how do I structure the questions properly?
How do I get good at spotting, at depth and things like that.
I do think the timelines are going to be compressed.
Essentially, something we also mentioned is individuals are becoming leads very quickly because they're leading a bunch of agents and delivering more complex pictures.
So I think maybe even the definition of what is been here, what is been here changes a little over multiple years.
But I think we will still have people, Lord and House users, That's a fair point.
Yeah.
Yeah.
I wonder if I have a controversial take that I think that as much as AI is changing how we work, I don't know that I think it's going to have a giant impact on how we think about career paths.
I think that the folks that are leaders, aren't the ones who write the best code all the time.
Like that's not the thing that we're looking for in the folks that are the senior leaders in our teams.
We're looking for folks who can have like a vision of what our product is supposed to be.
We're looking for folks who can understand where we need to pivot.
We're looking for folks who can have good judgment about not just the code that we're writing, but the problems we're solving and the products we're building.
So yes, the actual mechanics of creating code are a lot different.
I haven't written code by hand.
in months now.
I honestly, I couldn't tell you the last thing I wrote by hand.
But I'm not sure that I see that that is going to be the differentiator in our career paths over the longer time horizon.
I think we're going to be looking for the same things in our leaders that we've been looking for before, that they are able to wield the tools at their disposal effectively, and they're able to foster that in other people.
This is a new tool that we're now needing to learn to wield in a new way.
But I don't know that I think that it's going to really fundamentally change what I expect of my senior leaders over time.
Shauna, so I agree and disagree at the same time.
And I find the point, you know, very interesting.
On one end, I feel that the structure of roles will be completely different, but I agree that the values are the same.
So everything you listed as things that are important to know, I agree, stay the same.
But I feel that how we would address roles these days, if we were to design it today, it would be different.
And in some ways, the industry was going in that direction already, and some it wasn't.
So for starters, I feel that today...
People who have one skill.
So the developer who loved, you know, the details of the library, not that relevant anymore, right?
And whoever distinguished architects from developers, from tech leads, from even managers, right?
So all of that distinction, in my opinion, is dead.
What you need is people with a large breadth of skills, and I won't even call it any more a T-shaped.
Your maturity to me is how good you are in the breadth of skills.
Now, we need to decide how many of those, right?
So I think Philip was mentioning maybe everybody's a builder now.
I personally wouldn't go to that extent yet, but definitely the distinction between I'm an engineering manager, I'm a principal engineer, you know, I'm this kind of engineer, back-end, front-end, all those.
categorization that people used to give themselves.
They should have been dead before, but they're definitely dead now.
So it is good software engineering practices with the goal of delivering something of value.
How we shape that is the big question mark to me right now.
But thinking that an engineer can have only technical skills now and not people skills or leadership skills would put them out of the market.
And the same for everybody else.
So to me, the direction is in terms of how the job changes, full cross-functional knowledge, we need to decide to what breadth, and the maturity is measured in how proficient you are in that breadth of skills.
What becomes very, very difficult, and I don't have a solution for that yet, is the balance between this and cognitive overload.
Because you can have the understanding, and then we were talking about one person team that I wouldn't necessarily appreciate, love at this point in time.
What we need to understand is the new metric of how much can I be accountable for?
Not much I can ship, but how much can I be accountable using all the tools that I have at my disposal?
Those to me are the new criterias of responsibility, of skill sets, of engineers in the broader term.
And I think that will be a massive shakeup in our industry going forward.
I definitely agree, Vanessa.
I think that from my perspective, a lot of our organizations really struggled with this career path concept way before AI existed.
AI has made it worse that we're struggling with this, but it has exacerbated a problem that I think existed the whole time.
I agree.
Critical thinking and creativity at a wide societal level.
World Economic Forum saying we're losing the ability to think critically as a society.
What's that doing within our industry?
And where does creativity come into it now?
I spoke about creativity at QCon earlier this year, actually.
It's a kind of pet topic of mine.
I think creativity is going to be more important than ever in the age of AI.
When I'm working with AI, It can write code, it can write syntactically correct code and very good code, probably better code than I can write.
But can it come up with creative solutions to problems?
I find often it can't.
I think it goes further than that, actually.
And if you look in history and you look at other massive technological revolutions which have enabled us to create unprecedented speed and scale.
So, for example, photography can create an image immediately, whereas previously you have to draw.
every line by hand and paint every stroke by hand, that unleashed a massive wave of creativity in the visual arts that led to abstract art, impressionism, and all the amazing things that happened in visual arts after the invention of photography.
If you also look in architecture, parametric design freed architects from having to decide which bolt to put where, what the beams were, what the exact structure is.
You would just specify the constraints.
You'd say, I want it to bear this load and have this shape, and the software would generate the structure for you.
And that's led to an incredible explosion of creativity in architecture.
And I think the same thing will happen in AI.
This ability to create at incredible speed just means creativity is more important.
And there will be a creative explosion of ideas because now anyone can build, anyone can generate, anyone can make an app, anyone can make a website.
I agree with that.
There has been proof that constraints can actually improve creativity.
It's because now you don't have so many choices and unlimited things to think about.
You're no longer worrying about.
I think a debate used to have a lot of the time was what language, what...
library, a bunch of things that maybe we didn't need to debate as much.
And they're off constraints in terms of now we can focus on solving the actual problem.
I think a combination of the model getting better, people getting also better problem solving with this new tool, just like any other tool, like the example of the new tool camera.
People just having more experience with it.
I think we'll only share.
a different type or different wave of creativity and problem solving.
I agree with that.
And I sort of want to link it back to the previous topic because whilst I can open up my agent right now and write code and I can write my own app for my own things doesn't mean that if I work for a bank, I'm now going to write the most super secure transaction processor ever.
So just because I can do it doesn't mean I should do it.
With creative thinking, if you look through all the skill sets, whether it be the PMBOK, whether it be the BABOK, whether it be in the testing field, all of those for many years have had a part of critical thinking being an important part of those roles.
What concerns me is that even though the CEO can open up their agent and do all the things, I'm just thinking of the team I'm in right now.
We need some really secure and well-defined architecture.
I mean, I just recently was trying to figure out how to install a...
some stupid open source thing onto a Linux box, way out of my depth, got it most of the way there, couldn't get it there.
Why would you let me then loose in the open world?
I'm thinking about an architect I've got who understands AWS intimately.
And same with product people, they understand products intimately.
So I think what this does is allows us to open up the collaboration, that creative thinking in conjunction with these tools that can give us those great ideas, but we still need those core skill sets.
So when we are talking about bringing people in, if we lose the art of business analysis and project management and software engineering and architecture, then we're going to lose a lot of things because just because we can think out loud doesn't mean that we shouldn't still have those skills that can make sure that these tools are heading in the right direction.
Those humans in the loop that are able to then bring it back and go, yes, we can do that, but here's the reasons why we might need to rein this in, or perhaps at least know the prompts we need to tell the engines in order to make sure that we actually get the desired output that we need.
Additional to the skills that Craig mentioned, which are important in there, is the thing of domain knowledge.
It's the thing of understanding your customers, understanding what your business is trying to deliver in there.
You need that understanding to work with people.
You need that understanding also to work with AI.
You need it to ask the right question.
You need it to validate the output.
So the key thing in there is still knowing what your customers need.
And still, the easy way to find out what your customers need is to talk to them.
It's back to plain communication.
It's just connecting with your customers, asking for feedback, bringing out a product, bringing out a part of a product or a new feature, and see how that feature is being used.
And also being open to any information that you get in there.
And that's, again, related to how safe do you feel when you get information in there, which might contradict what you think.
You might be wrong.
Are you willing to accept that and to adjust your behavior if you figure out that you're not the right thing?
You're not doing the right thing?
I think that's a key skill that people still need.
Another topic I'd like to explore, which leans on some of this.
is the just because we can, does it mean we should?
And I want to delve into the ethics of our industry, the ethics of the products we use.
What does ethical computing, ethical engineering look like?
Ethics is a broad topic, and I'm not a philosophy major.
From my perspective, I find my asking myself whether it's ethical for me even sometimes to just...
ask, you know, an AI, something I can ask Google, or I can research in a book.
Now, this is a small piece of this.
And in general, I think when we talk about this and ethical engineering, what we want to focus on is, are we sure that we are protecting our users that are protecting our colleagues that are protecting the world?
Like how are we building things that will not backfire for us?
This could be from a business perspective, from a human perspective, from an individual perspective.
The moment we lose full control of what we're doing.
We don't know anymore how to be accountable for our actions.
If I, let's say, miss something in a PR or I'm not fully accountable of a system I'm building and then it leaks so much data for our customers and it causes so much damage to society, am I actually going to feel accountable for it?
And I think this piece is missing a lot in our usage of AI these days.
We used to have a very tight contact with our code and we still miss things.
The more we can build, the less we can understand.
So we need to figure out how to have that sense of responsibility towards what we build.
And this can span multiple aspects.
It could span resources.
It could span society.
It could span, you know, even the livelihood of your company in multiple levels.
But the thing that we need to do as professionals these days is feel accountable for the code we deliver, whether it was written by AI or not.
Unless we are so confident with our harnesses around the system that then we are accountable for those.
But it has to be very, very clear and very, very well structured to make sure that we can be truly accountable for what we deliver.
And not that people can say, but it was AI.
How could I know that?
It was, you know, one billion lines of code.
We need to put some controls around that.
not just our companies and our users, but like the world.
We understand that computing takes electricity, takes a lot of water.
We live on a planet right now that is maybe struggling more than it ever has before.
How do we use these tools in a way that is not...
putting literally civilization at risk over the longer time horizon?
If I knew the answer to this, I think I'd be doing something else with my day.
I don't know the answer, but it is a question I personally struggle with.
As I'm using a tool that I understand is more expensive than maybe anything I've ever used before, how do I wield that in a way that is not going to be damaging to the world over the longer time horizon?
Yeah, there's a risk of massive civilization damage, but also...
There's a risk, well, the opportunity on the upside.
What if AI solves nuclear fusion and then our energy problems are gone?
What if AI solves cancer?
There could be massive revolutions in healthcare.
So there's positive things that could come from AI as well.
I think those positive things are things that could be specifically targeted, right?
And the technology...
is something where you hear some world leaders talking about using good, clean coal to power.
People familiar with that quote will realize that people are willing to pay any price sometimes to scale.
And I see people picking the premium model sometimes when they shouldn't.
People who are not thinking and being intentional.
We have a tool.
Big hammer.
Let's use the big hammer.
We had one of these a few years ago.
Shame may remember the name of, was it Utah or?
Utah Epstein, yeah.
Utah Epstein, exactly.
She talked about being aware.
This was early AI days, but it was less to do with AI.
It was about being aware of the environmental footprint of your services, of your infrastructure, making that almost like a metric you measure.
Now, like, you know.
We're burning tokens.
We have a metric right in front of us that's a proxy for the impact of the work we're doing.
We're aware of it only because we can run out of tokens or we might get a telling off from someone or we'll hit a quota.
There's a project I mentioned earlier that I saw called MuralWatt, and I really love their model.
They expose open source models like GLM, but their pricing model is based on power consumption.
And they claim something like, you know, like you pay 40% less or something.
There's some really impressive stats.
It's a startup.
I don't know how long they'll last, but I love the idea of that model where you're paying for the power consumption as opposed to your token count.
And that might mean that if you're not got like a very resource intensive load or you're misusing the query, essentially we're exposing your environmental impact to you.
And I really love that.
And I'm not sure we're always thinking about it.
We're in a very critical phase.
I am a green voter here.
We're in a critical phase in terms of like, you know, not hitting carbon reduction targets.
And this great tool has come out and we're like, all right, we're going to produce new features and new this and new that.
And essentially, right, we're generating more energy in the outside of New Zealand, at least we're burning more carbon.
So that's a bit of a concern.
Good point, Rafa.
For me, in the short term, I've also really been thinking and concerned about something we've spoken about through this conversation, the impact on the individual and the impact on teams and the impact on our collaboration.
And there was the habit study earlier this year, which was showing that AI free intensifies work rather than reducing it for individuals.
So we're having a case where we're getting more worked more.
On the topic of safety and psychological safety, people are afraid that they're going to be replaced by AI.
I think it was something like 70-80% of people think their role is at risk of being affected by AI.
So people are more anxious, more worked, and we're still going full speed ahead.
I think maybe we're not asking, back to your point, Shane, you're not asking the question like, okay, we can do this, but should we?
Is this actually the outcomes we want?
Do we want to be more anxious and more overworked?
And I think possibly in the long term, we'll figure out better ways to, well, hopefully it's more of a hope rather than based on actual evidence, but maybe in the long term, we should go better ways to work and collaborate and use the system.
But in the short term, I think the effects on the individual and on teams are really, really intense.
That's something we need to figure out.
Phil, earlier mentioned the hyper-engineering, the faster pace of multiple things.
Back to the creative thing, I'm building a VR app in my own space to avoid paying a subscription for something.
So I feel super creative.
I like creativity, really, but I'm deluding myself.
But with this, I've got, you know, sub-agents going and doing segmentation on images.
I've got other stuff happening.
I'm using Superbowl's in Claude, which, you know, kind of handles some of the cognitive load for me and goes off and gives me choices.
But when I'm doing multiple things, which you feel inclined to because you don't want to sit on your thumbs, you do get into that space where you're just stretched across two abstract concepts and you're trying to context switch between them, which we've always sucked at, right?
We've always got the high cost.
We're seeing that in our teams as well, right?
People are trying to be more efficient.
They're trying to like not sit on their thumbs.
And what is the longer term cost going to be in terms of people's capability?
At the same time, something I've seen is engineers, some of us call this out, different levels, right?
Not get the same result from AI because there's some people who know what to look for in terms of like the output produced.
There are others that are relying heavily and trusting heavily.
the result of their sessions.
And they're not equal.
And there's a risk being introduced.
And perhaps the desire to learn and grow and be better at your role is not there.
All right.
I'm going to do a quick round.
What do you wish for our industry for the year going forward?
And Vanessa, I'll start with you again.
Thank you.
So for the year going forward.
I wish a little bit more of mindfulness.
We have a beautiful instrument in our hands.
I wish we willed it in the right direction in the respect of people, the environment and, you know, business growth.
We're powered by business growth, but there is a way of being a little bit more mindful toward what we do and to make sure that we don't lose all the good things that we've built up to now.
Ben.
Well, I would wish that we all keep out an eye for each other and just check how other people are doing in a more general sense.
Like if you feel like somebody is losing stuff, if somebody is missing the boat, if somebody doesn't feel comfortable with what's happening, take some time and check with them.
Like, okay, are you still on board?
If there's something you're worried about, can you say it?
But make sure that we keep the people aspect in there, no matter how many.
tools or machines or whatever that we are using.
We're still people.
For me, I'd like to see a greater focus on quality and testing.
You can build incredibly quickly now, but are you building something that is robust and valuable?
That's what I'd like to see.
Raph?
Humanism again.
We're all going through this massive transformation, right?
And the comparison to the Industrial Revolution, skills we've acquired over years.
not as valuable as they were, but the mission we were on to deliver great products, build great products that met real needs, that hasn't gone away.
And as we go on that journey, I think just compassion and humanism for those around us, for the customers at the end of it, intentionality, as Claver and Arkes said, I think all of that really really matters.
So we shouldn't lose that.
Sure, man.
I think that I hope for us to not just focus on what's changing about our roles, but to not lose sight of what's staying the same.
I think AI is changing part of our day to day, but the role of our senior leaders needs to be to foster the folks that are coming after us and to build products that solve problems and to try to do it with as little impact, negative impact to society as we can.
I think AI is getting a lot of focus right now.
I would hope for us to maintain that.
I think it's an incredible kind of unbelievable tool, but not lose sight of the parts of our jobs that need to stay the same.
I'm hopeful for the conversation to shift and for more focus to shift from just outputs and metrics, things that lots of people are focusing on right now to collaboration.
creativity and the more human elements of our work, which we've all enjoyed and loved over the years.
So a lot more focused towards helping us work better together and enjoying our love more.
Greg?
Continue to see the embrace of both humanity and innovation.
Many have just spoken about the humanity part, the collaboration, human in the loop, people working together.
That's what got us to this point.
That's what's got us all these technologies.
Let's not lose sight of humans in the loop and human beings working together and helping each other out.
And innovation, meaning that innovation is more than just the AI and the AI innovating.
We talked before about how do we make sure that our work practices are innovating as well.
And we need humans in order to do that.
How do we get better things out of these tools?
That's where the real innovation is.
So people working together to innovate and make things better.
but not just relying on the stuff that comes out of the tools.
The real innovations come from people collaborating and talking to each other.
This is the engineering culture space.
And I want to lean into a Maori proverb.
Hei tangata, hei tangata, hei tangata.
It's the people, it's the people, it's the people.
Everything we do is about the people that we serve.
Folks, thank you so much for being part of our trends report for July, 2026.