The panel discussion in this episode is one half of the annual InfoQ Culture and Methods Trends Report. The other half is the written report.
This is the Engineering Culture Trends Report for 2026. Featuring a panel of QCon speakers and InfoQ contributors, they discussed AI adoption maturity and risk, the transformation of engineering team structures and roles, and the human dimensions of software development that must not be lost in 2026.
Key Takeaways
- AI adoption demands maturity frameworks that assess risk and context and organisations must be honest about what they are actually trying to achieve with AI in their specific circumstances.
- Collaboration patterns are changing fundamentally: teams are shrinking, roles are blurring, and the question is no longer how to structure teams but how to make collaboration more effective in whatever form it takes.
- The explosion of AI-generated code demands entirely new processes for quality, cognitive load management, and accountability.
- Organisations that failed to embed agile fundamentals face catastrophic risk with AI adoption; fast feedback loops, observability, and shipping the right value to the right users remain as critical as ever.
- Engineers are shifting from contributors to custodians: the defining future skill is not writing code but effectively directing, validating, and building guardrails around AI agents.
- The industry must confront the environmental costs of AI usage, the erosion of diversity of thought from homogenised agent outputs, and the accountability gap when no individual fully owns AI-generated systems.
Subscribe on:
Transcript
Shane Hastie: This is Shane Hastie, and we are 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?
Introductions [01:20]
Vanessa Formicola: Thank you. Good morning everybody. So I'm Vanessa Formicola. I'm an engineering leader, sociotechnical architect. It means that I work on both technical leadership sides, and in general, I try and fix problems in the system.
Shane Hastie: And moving around, I've got Ben Linders. Ben.
Ben Linders: Thank you, Shane. Ben Linders, one-person company, mostly focused on the social aspects of sociotechnical team collaboration, people, safety, reflection, learning. That's the kind of stuff that I'm focused on.
Shane Hastie: And Philip.
Philip Mortimer: Hey everyone. My name's Philip Mortimer. I'm a machine learning engineer specializing in document intelligence. My background is mostly in finance. Used to work for a bank and most recently in FinTech.
Shane Hastie: Yinka.
Yinka Omole: Hey everyone. My name is Yinka. I'm a software engineer. Also have a background in finance. So I used to work at a bank currently at an HR tech company. Mostly working in IC nowadays.
Shane Hastie: And Raf?
Rafiq Gemmail: Raf Gemmail, based in New Zealand. I have been in the industry since... Well, I've been cutting codes since about the '80s. I'm a senior director at MarTech. 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.
Shane Hastie: Welcome. Craig.
Craig Smith: 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.
Shane Hastie: And Shawna, welcome.
Shawna Martell: Thank you so much for having me. I'm Shawna Martell. These days a principal, engineer in the FinTech space. Spend a lot of my time thinking about how to really foster our staff plus engineers in our organizations.
Shane Hastie: Yes. 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 sociotechnical systems and leadership development, growing teams, growing people, and figuring out how we work most effectively as human systems in this sociotechnical 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.
AI Adoption Maturity and Risk [04:22]
Vanessa Formicola: Thanks, Shane. 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 are 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 conversations we used to have in the past. And I feel that these days is more everything or nothing in the AI space.
Shane Hastie: So how do we move away from that everything or nothing?
Vanessa Formicola: It's more how do we apply the same reasoning that we've used in the past? What's the risk? What's the impact? What's the specific circumstances of level of maturity, let's call it. Not necessarily with a 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.
Shane Hastie: Cool.
Vanessa Formicola: So frameworks of maturity for i.e. acquisition, I would say.
Shane Hastie: Frameworks of maturity. And jumping across Ben, what are your thoughts? What is the thing that people should be thinking about today?
Psychological Safety in the AI Era [05:51]
Ben Linders: 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 in the opportunities that passed by.
I think that's where the adoption of AI having a great impact. And I think it's also tied to the maturity, I would even say more capability. The maturity, 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 the teams work.
Shane Hastie: But haven't we been tackling psychological safety since at least 2014?
Ben Linders: 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.
Shane Hastie: Thank you. Philip.
Philip Mortimer: Yes. 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 hyper velocity engineering, compound engineering. We're working on multiple work streams at once. We 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. For example, the pull request process. Can you really read all the code that AI generates?
Shane Hastie: Yes. One figure that we've had on the podcast was 300% more code, 400% more bugs going hand in hand.
Cognitive Load and Hyper-Velocity Engineering [08:17]
Philip Mortimer: Yes. I saw recently that GitHub is going from I think one billion pull requests per year to something expected 14 billion pull requests per year predicted for 2026 from one billion last year. That's a 14x increase. We need to build the systems that lets us manage and understand what we're building.
Shane Hastie: 14 times the cognitive load. We're already buckling under the pressure. Raf, what are you finding?
Value and Return on Investment [08:49]
Rafiq Gemmail: I think I'll echo what Philip has said to some extent in that Vanessa's point around value and 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've really tried to emphasize that need to keep asking, what is the value we're delivering?
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. 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? 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 preceded where we are today.
Harness engineering, for instance, is very much in my mind, staffing analysis plus other guardrails and whatnot. But there are practices that we've had to date that have been 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 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.
Agility as Foundation for AI Success [10:29]
Shane Hastie: Jim Highsmith has said, "If you failed at agile, you will fail catastrophically at AI".
Rafiq Gemmail: 100%, I think.
Shane Hastie: And yet many of our organizations still haven't embedded the fundamental principles of agility in their ways of working.
Rafiq Gemmail: And fast feedback loops, I'm just going to throw out there. I see a lot of people trying to run who skipped some of those steps or you didn't really refine them. And now to Philip's point, massive PRs, risk is bigger, chunk size is a bigger. How do we have confidence that we're pushing them out? We got the right observability in place. Have 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.
Shane Hastie: Craig.
The Gap Between Haves and Have-Nots [11:17]
Craig Smith: 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 tending software's 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 request? How do we deal with quality?
Is the same machine that just built the same engine that is also testing to 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.
This is a brave new world and 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.
Shane Hastie: And Shawna.
Defining Value When Code is Abundant [12:34]
Shawna Martell: 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 ship 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?
Shane Hastie: Yes. When knowledge is a commodity and code is easy, how do we know what value actually is?
Shawna Martell: 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?
Shane Hastie: 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.
The Role of the Engineer is Changing [13:43]
Yinka Omole: Yes. I think hearing a lot of what's been said, for me, a quick summary is that the role of the engineer 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, I guess, platform engineering where now we're developing platforms for agents to be able to write the code, and then for us to 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 are adopting AI usage, but fewer people are trusting the outputs, which a really interesting contradiction. And I think as engineers, our role would evolve a bit more into driving that trust factor up by building more systems, building more guardrails, building more things that make it all work together and drive proper business outputs.
Shane Hastie: 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 teams becoming a one pizza team. 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?
The Evolution of Teams [15:56]
Vanessa Formicola: 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, okay, this team requires this skillset, this software will last, this software will be for the developer user, for the actual user pay in 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 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 the team up to now, but super powered by models, agents and supporting what they can. And I can see lower risks teams where it's actually product manager in one dev.
This can open roads to completely different setups of teams, 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 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 your organization or even your risk factors of hyper-generating an 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.
Blurring Roles: We're All Builders Now [18:26]
Shane Hastie: Philip, you were going to say something.
Philip Mortimer: Yes. 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.
Ben Linders: 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 that 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 product in there. Could be a whole organization based around model IDs 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.
Yinka Omole: That's a great point. It's got some really interesting learning in terms of what makes up a team. Particularly some other things I've seen is that you're going back to the old article from some trendsetters around the engineer-manager pendulum, seeing a lot of managers swing back into being engineers and 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've seen probably previously roles that were very specific. In a team, you could have a front end, backend infrastructure 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 it lost your sense of organization. So how can it help us not just live more as individuals, but actually collaborate more?
Collaboration in the One-Person-Team World [21:20]
Shawna Martell: I think one of the dangers of these one-person teams is it takes away some of the collaboration that we expect from our work. 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 part of the joy of work is getting to work with other people?
Shane Hastie: Yes. 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.
Shawna Martell: Shane, I feel like you're telling me I'm going to regret my words in a month, which maybe I will. Maybe I will.
Shane Hastie: Technical use of software, autonomous agent generation as numbers fives 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 yes, therapy and companionship is number one. Craig, did you have any thoughts on this one?
Craig Smith: Yes, I echo all the thoughts that the people have said. We talk about the one-person team, and I think that's a 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 in 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 here 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 forward outcome. And 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, slop around the place within our teams. It's a real concern.
Philip Mortimer: Yes, 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 lose that if your teams are degenerating to a bunch of one-person teams all working on completely independent projects.
Shane Hastie: Raf, you're leading some of these teams. What are you seeing?
Junior Engineers in the AI Age [24:52]
Rafiq Gemmail: I can't talk about with specific context because rules, but I'm definitely seeing smaller teams. And to take an external example, someone was talking to me about a gig recently with a tax company that had tried to vibe code, rebuild of a tax 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 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 as you open up these doors to say, "Hey, everyone can be t-shaped". Getting t-shaped was never just an easy journey. It was a journey of 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 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 yesterday actually by Daniel. And thank you, Daniel. And he re-shared 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.
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 SDD 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 say a junior. And they already 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 guardrail. Don't do this again. Right. Right. You were logging this to the wrong system or you were using the wrong library. You set 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. And I've heard the term even used and tiger teams, all sorts of shit. And it hurts me a bit that we're going back to that place where we knew for a long time the rockstar 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 a 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.
Shane Hastie: 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?
Rafiq Gemmail: 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 engineering, he 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 Yegge 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 maybe more advanced concepts around, is this heading in the right direction for the product? Is this something we can merge? And 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 a level of maturity you have to reach even to have that entry level guardrail.
Shane Hastie: Philip?
Senior Experience as Force Multiplier [30:01]
Philip Mortimer: I think right now we're in this 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.
Rafiq Gemmail: Yes.
Philip Mortimer: 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 to a year's time, we'll be there.
Rafiq Gemmail: I guess the thing I wonder about quite a bit, Philip, is yes, they will be very good with the tools, but engineers were very good with the tools. The challenge is sometimes growing to the point where you are very good at asking the right questions. You're very good, not in terms of agentic questions, but about the product you're building, the problem you're solving. What am I trying to solve here?
And that depending on the individual can tell you quite... It's a journey and it's lots of little micro realizations and getting straight there, maybe it's just a better agent that's taught or coach you in good sound product decisions, but the individual, I'm curious to see that people go on that journey.
Yinka Omole: I think it's going to be very messy in the short term, but I do think in the long term, the way as junior engineers learn is going to be different. I think for many of us learning over many years was like what we said, learning how to ask the right questions, learning fundamentals. But big chunk of it was also learning the implementation of how to write good Java code or how to write good C, and things like that. And that's not as necessary anymore.
So it frees up a bunch of mental bandwidth to then focus on the things you mentioned, like how do I structure the questions properly? How do I get good at spotting tech debt and things like that? And I do think the timelines are going to be compressed. Essentially something we also mentioned is individuals are becoming leads very quickly because when you're leading a bunch of agents and delivering more complex features.
I think maybe even the definition of what has been here, what has been made changes a little over the next few years. But I think we will still have people learning how to use the skills and maybe junior levels engineers and I think they will still be necessary to learn these fundamentals and maybe they won't spend as much time figuring out because they don't need to anymore.
Rafiq Gemmail: That's a fair point. Yes.
Shane Hastie: Shawna, look like you're about to say something.
Career Paths and Leadership Skills [33:16]
Shawna Martell: Yes. 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. 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 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.
Vanessa Formicola: Shawna, so I agree and disagree at the same time. And I find the point 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 the details of the library, not that relevant anymore. And whoever distinguished architects from developers, from tech leads, from even managers. 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. 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, I'm this kind of engineer, backend, 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 and love in 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 criteria of responsibility of skillsets of engineers in a broader term. And I think that will be a massive shakeup in our industry going forward.
Shawna Martell: 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.
Vanessa Formicola: I agree.
Creativity and Critical Thinking [37:36]
Shane Hastie: Critical thinking and creativity. At a wide societal level, World Economic Forum saying we are losing the ability to think critically as a society. What's that doing within our industry and where does creativity come into it now?
Philip Mortimer: 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, you 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, our metric design, 3D 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.
I think the same thing will happen in AI. This ability to create an 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.
Yinka Omole: No, I agree with that. I think 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 the debate used to have a lot of the time as what language, what library? A bunch of things that maybe we didn't need to debate as much, a bit of constraints in terms of now we can focus on solving the actual problem.
I think a combination of model gotten better, people getting also better at problem solving with this new tool, just like any other tool, like the example of the digital camera and people just having more experience with it, I think will only share a different type or different wave of creativity and problem solving.
Maintaining Core Domain Skills [40:28]
Craig Smith: 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 process ever. So just because I can do it doesn't mean I should do it.
With creative thinking, if you look through all the skillsets, 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 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 loosen the open world with... 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 skillsets. 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 are 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 reign 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".
Ben Linders: Additional to these skills that Craig mentioned, which are important 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 needed to ask the right question. You needed 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 customer 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 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.
Shane Hastie: 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 of AI-Enabled Engineering [43:45]
Vanessa Formicola: 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 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 in 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? 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 are 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 damages 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 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 one billion lines of code". We need to put some controls around that.
Shane Hastie: Shawna.
Environmental Impact of AI [45:50]
Shawna Martell: Building on what Vanessa just said, it's kind of like how are we impacting not just our companies and our users, but 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?
Philip Mortimer: Yes. There's a risk of massive civilization damage, but also there's the 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? It could be massive revolutions in healthcare. So there's positive things that could come from AI as well.
Rafiq Gemmail: I think those positive things are things that could be specifically targeted. 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. Shane may remember the name of... Was it Jutta or-
Shane Hastie: Jutta Eckstein
Rafiq Gemmail: Exactly. She talked about being aware, this was early AI, 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 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 will hit a quota. There's a project I mentioned earlier that I saw called, Neuralwatt, 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 where you pay 40% less or something.
It's some really impressive stats. It's a startup. I don't know how long they'll last, but I love that 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 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 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 we're generating more energy outside of New Zealand at least we're burning more carbon. So that's a bit of a concern.
Human and Team Wellbeing [49:13]
Yinka Omole: Good point, Raf. For me, in the short term and 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 Harvard study earlier this year, which was showing that AI really intensifies work rather than reducing it for individuals. So we're having a case where we're getting 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 at least their role is actually at risk of being affected by AI.
So if 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, asking a 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 work rather than based on actual evidence, but maybe in long term, we figure out better ways to work and collaborate and use the systems. But in the short term, I think the effects are on the individual and on teams are really, really intense. So that's something we need to figure out.
Rafiq Gemmail: Philip earlier mentioned the hyper engineering, the faster pace of multiple things. Like 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 like super creative. I like creativity really, but I'm diluting myself. But with this, I've got sub agents going and doing segmentation on images.
I've got other stuff happening. I'm using superpowers in Claude, which 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, which has always got the high cost.
And we're seeing that in our teams as well. People are trying to be more efficient. They're trying to 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, someone else call this out at different levels, 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 of the results 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.
Shane Hastie: 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.
Wishes for the Year Ahead [52:23]
Vanessa Formicola: 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 wield it in the right direction in the respect of people, the environment and 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.
Shane Hastie: Ben.
Ben Linders: 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. If you feel like somebody is losing stuff, if somebody is missing the boat, if somebody doesn't feel comfortable 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.
Philip Mortimer: For me, I'd like to see a greater focus on quality and testing. You can build credibly quickly now, but are you building something that is robust and valuable? That's what I'd like to see.
Shane Hastie: Raf.
Rafiq Gemmail: Humanism again. We're all going through this massive transformation 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 Venessa said, I think all of that really, really matters. So we shouldn't lose that.
Shane Hastie: Shawna.
Shawna Martell: 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 and 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.
Shane Hastie: Yinka.
Yinka Omole: 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 element 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 work more.
Shane Hastie: Craig.
Craig Smith: Continue to 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 then 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.
Shane Hastie: This is the engineering culture space and I want to lean into a Māori proverb. "He tangata, He tangata, He 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.