# AI Amplifies Engineering: Context, Specs, and Organizational Strategy

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-02-05

## Transcript

Hello everybody and welcome to another edition of the ThoughtWorks Technology Podcast.
I'm one of your regular hosts, Ken McGrage.
I'm very spoiled this week.
Happen to be in person with a couple folks I've known for many years.
So it's great to see you both.
I'll let them introduce themselves first, Nathan Harvey.
Hi there, uh Ken, good to see you.
I'm Nathan Harvey.
I lead Dora at Google Cloud.
So you might know of Dora.
It's a research program that looks into how do teams, technology-driven teams, get better.
And Patrick.
Yes, my name is Patrick, and I currently work at TESL, and I'm usually known for my work around DevOps.
And I got really excited about these whole Gen AI craze right now.
And this is my day-to-day job.
Cool.
So it's okay, Nathan, I'm going to start with you.
So part of the Dora thing is more of the AI focus this year.
You talk about it in not fixing broken teams, but amplifying what's already going on.
Can you expand a little more on that?
Yeah, one of one of the people in our community has described it as like, you know, you have a like a high school band.
And when you hook up the band to the amplifier, maybe you didn't want to.
It just got louder.
It didn't get any better, just louder.
But then you get a you know, a professional band and you hook them up to an amplifier, and that's that's great.
You know, you can hear them better, they're richer sound and so forth.
And what we're seeing in our research is that that's kind of like how AI is working.
In a team where you've got good flow, good communication that's happening, you know, solid testing and so forth.
When you add AI, throughput and stability are going to improve.
You're gonna be able to ship more and so forth.
But when you're working in a team where that's not the case, maybe, and kind of the canonical example I always go to is like maybe your code review process or approval process takes a long time.
Well, now you've introduced AI and you're generating 5x, 10x, 100x lines of code, and you're sending it through that same constraint of that review process, you're gonna feel the pain of that review process even more acutely because it's it didn't scale with your ability to scale code.
So that's really what that amplifier effect kind of feels like.
Cool.
And then Patrick, you've been talking a lot lately about a shift from producer to a manager of agents.
Um so where humans aren't writing the code.
If that's the case, where's the engineering happening?
Like Nathan said, there is a point where you have to judge whether something is good or not.
And that's takes practice and learning.
Now, I wouldn't go per se that far as you know, we need to always have all the best practices at hand.
And that sounds very weird coming from me, you know, but it there is a certain truth in it, is that sometimes you need to get something out.
And it's all about the risk profile.
If it's okay to get it out and the risk and the containment is actually okay, then you can push it out without having all the tests and all the rigor.
So it it kind of is a game that is dependent on that.
Now, in addition, while AI is you need to know what good looks like, I also observe that when you're new to certain things, let's say you're learning a new language, it's actually accelerating your learning phase as well.
Now you're stumbling still, maybe through it, like you were doing in the previous pod, but you have almost like the tutor that helps you all the time to get better.
So it's there's kind of merit in both, kind of you know, leaning into engineering and then kind of having it assist you and uh kind of making sure you judge that right.
Um, we all have to learn it, and it's gonna be the same for everybody.
Like, what is that correct judgment that we need to call?
I I I love like both of those instances kind of echo the amplifier effect as well, right?
We just need to get something out.
We maybe don't have time to test it, we want to get some fast feedback on that.
Well, do you have the ability to progressively roll out a change?
Can you roll it out to a small subset of users and then get feedback?
Or is everything everyone all at once?
Because that changes the risk profile, which is exactly what you were talking about there.
And then also uh this idea of using AI as a tutor or a way to help you learn about a new language, a new framework, a new domain.
That to me, like that's the heart of engineering is this curiosity, and we're always trying to learn.
But not everyone approaches new technology or or their work that way.
And so, again, we can leverage the AI to help us learn, or we can ignore the learning and just you know, damn the torpedoes, we're just we're just shipping to production.
So, you know, we talk about just in society, wage gaps and that kind of stuff and knowledge gaps.
Um, are we in danger here of creating a permanent underclass?
The folks that don't have that engineering rigor and they're just rolling stuff out as fast as they can.
I mean, is is this is is there a danger here of making the gap get bigger, or what can we do to bring everybody along?
So I I personally argue that uh they're all gonna go through a a learning phase, right?
Imagine you're just pushing things out, your first failure happens.
What do you do?
Oh, I have to have a better way of doing like my observability or see what happens, or kind of deal with the failure of or or I had like forgotten a backup, right?
So people stumble their way like we would do that.
Again, depending on the risk, that that's uh the the thing you do.
But that kind of going as you um learn is just inherent uh to kind of that phase in my opinion.
Yeah, I think you're gonna continue to see those failures, that fail those failures are where the learning happens.
And to your point, Ken, like are we gonna are we gonna have sort of the stratification of the people that know the old way and are now leveraging AI and so they're better?
I don't know.
I I never learned how to ride a horse, but I can drive a car really well.
And I I bet when the cars were coming out, there were people that were like, those people cannot drive a car until they know how to ride a horse.
I don't think I I mean I think this is what's so exciting is that things are changing, right?
You don't have to, you don't have to have been in a data center to know how to use the cloud.
And in the same way, in the future, you won't have to have written code by hand in order to be a software engineer.
It's uh the ability almost to unlearn uh is quite important because we accumulate a lot of knowledge while we're learning.
And there's a certain paradox you would say, oh, I'm getting better and better and better, but in my head, I have like adding checks, checks, checks that I need to do.
So eventually, with all the knowledge, I become slower compared to somebody else who just get it out.
Now there's again a person getting it out and they get it right, they are faster than us doing it slower.
So it's again like there's a paradox in having kind of all that knowledge that can hinder us in that perspective.
Yeah.
So there's a lot about uh intent-driven delivery and spec as code.
I know Patrick, you've talked about this.
Uh you propose that specs are the new code is uh in one of your articles or talks recently.
You know, if we move towards that intent-driven, do we still need a traditional delivery pipeline?
You know, I mean, what does that do to how we actually take software from idea to cha-ching to use John Willis's term?
I would say that the engineering might happen now more at the layer of the context.
And specs are one way of providing the right context for the AI agents to do something.
Much like you know, you have an informed person making decisions as they do certain coding, um, and kind of making sure that like the agent knows what to do.
Now it doesn't stop just on the specs, it will be while it is working as well.
Oh, we didn't have the best practices documented, we didn't have those things.
Now you can say everything that is context is a spec eventually, uh, but it's also all context.
Now, the problem we're currently facing in the industry, uh, while I say, hey, uh specs are the new code, is that the systems have limits on context window.
Now we're getting a better better techniques to kind of load in at the right time, the right context, but there is still kind of a lot of fiddling between the models understanding all the context.
And that's the challenging part.
So it's not yet true, but it might be more aspirational, but it does give already better results.
But if you start writing up documents like we used to do in waterfall, it's gonna have the same effect.
They're gonna grind to a halt and they have to comply with everything, and it's not something.
So there's an iterative process while they're doing certain, you feed it the right amount of information, and then it does the job.
And so the upfront design is again also with AI failing right now.
Yeah, I think it's it's super fascinating because as you said, the the context windows, and and we we even think about things like context pollution.
Like, are we providing the wrong information or too much information to the bots when we ask them to go and build something?
And so I think you know, techniques like progressive disclosure and working in smaller batches still are really, really important and can get you to a better outcome.
Uh so I think that that's really fascinating.
I also think that when it comes to the context and the specs, like these are probably things that we want to start treating as part of our artifacts, checking into version control.
You're already seeing people today sharing their agents.md or claude.md files out on the internet.
And the thing that I find so fascinating about that is you have senior engineers with all of this skill that for the first time ever, maybe, are actually writing down this is my software development practice.
And the thing I find fascinating about that in particular is, you know, they've been very hesitant to write that down to help a junior engineer become a senior.
But they have no hesitation writing it down to help a bot write better code.
But the the side effect of that is that it's written down in a public place now or in a shared place.
So you're you are helping those junior engineers start to build up that practice as well.
So I think that's uh it's certainly an optimistic view of of how that's going.
I do think that context becomes king and and and being really clear about what problem we're trying to solve.
I think that context also then can go feed into the feedback mechanisms that we have.
The context is there not just to build the application, but also to build the verification specs, right?
How do we know that it did what we wanted it to do?
That's important.
The the difference I think is right now the senior or well, whoever engineers who write kind of the context, it helps them.
While in the past it helped the others.
So that's why a lot of people are doing this.
Absolutely.
Absolutely.
To get there.
Um the versioning is interesting because writing a Claude MD for yourself is what a lot of people do.
It's almost like this is the BOP script that worked on this laptop.
Uh-huh.
So there's also kind of like we've been looking into that, like using more rigor engineering evals to see whether your Claude MD is actually good.
So think of this as a linter that you actually see which of the pieces should be loaded.
Because if you like we mentioned, when you overload that Claude MDE with too much information, you might put best practices, but they might already be in the model.
So why are you putting them in there?
So but then the models evolve.
So there's kind of constant engineering on that piece happening.
And so it might be less on the code, but now we have a new kind of discipline and work to be done.
It's something that we probably should use software engineering practices to manage, right?
It's checked into version control.
We do code review of this file and and and we build that shared understanding of it.
I think that's really fascinating.
I was just listening to another podcast.
I won't mention it because you know competition.
But on this podcast, it was the creator of ClaudeBot was there, and he was saying, uh on this open source project he's working on, I don't want you to submit pull requests.
I want you to open up issues that are a prompt that I can now feed to the agent.
Because that prompt that you're uh giving me, that tells me more about your intent.
What are you trying to accomplish?
And I'll let the bot write the code, and then I can judge whether or not that's the right code to weave in.
And and maybe that's better.
And maybe that's a a place that we're moving towards.
He called them not pull requests, but prompt requests.
That's what we're after.
Interesting.
So our our goal here is to educate the listeners.
If it's a useful podcast, please do tell them what it is.
It was the pragmatic Engineer podcast.
They all listen to that one already anyway.
Okay.
Um and so I guess for Nathan, you know, we we're all about like metrics and those kinds of things, right?
Especially in your world.
Uh you know, we have agents that can do a thousand pull requests.
Does deployment frequency even matter anymore?
Oh, well, a pull request does not necessarily equal a deploy.
So yes, I think deployment frequency does still matter.
I think that one of the things that Dora has shown over the years is that those teams that are better at software delivery performance, primarily measured as throughput and stability, those teams tend to have better organizational outcomes, higher revenue, better profit, better customer satisfaction, and at least as importantly, better well-being for the people on the team.
And I don't think whether it's an agent that wrote the code or a human that wrote the code, I don't think that changes, right?
That software delivery is still like the reason we deliver software is for users.
That drives our business forward.
And being able to do that in a friction-free way makes it much better for me as a human.
And so I think that the deployment still matters.
Now, to your point though, now we can have a hundred pull requests, maybe going back to what I said earlier.
Well, what's your process after the pull request has been opened?
A hundred instead of one might actually, be harmful for your organization.
So I think it's important that we're thinking about the entire system, not just how quickly can we write code.
Yeah.
And I I want to add to that because I agree that these um traditional metrics, they kind of stay useful.
But one of the upcoming new ones, uh, especially in the context, no pun intended, uh, with the context engineering, is how many touches does your AI need given from your question to actually get like something that you want?
So that's something else that you can start to measure, and that's kind of pre-delivery, but it's part of the whole chain of delivering those things.
And then another interesting aspect that I saw is that while we're delivering pieces and there's often business pressure on requests from end users, like I want this to be built.
There's some tools that allow you almost to have the end user vibecode something on top of your application to actually see what they want it to build and then feed that back to you.
So it's not a prompts, but it's almost like they give you working prototypes on top of your product.
Yes.
And it's like the ultimate feature kind of uh discovery uh of people vibe coding on your platform.
Anyway, that's it's fascinating.
I I I love it, and it like, yeah, super interesting times.
Yeah.
So if if intent is the primary driver, um, how do we prevent a future where no one on the team knows what's going on when something fails?
And I didn't say if, I said when.
You know, so when an agent fails, how do they, if they don't, if the intent was the driver, how do they understand the underlying system?
Yeah.
I I mean, I think that I think there's like two parts to the answer, maybe.
Uh the first part being, does it matter?
Uh, you know, I I I've I'm starting to see and participate in some conversations where we're questioning like, does the the way that we construct code, does that matter anymore?
The way that we name a function, the the cyclomatic complexity.
If the agents can deal with it, let the agents deal with it.
Maybe it doesn't matter.
And yes, things are going to fail.
Guess what?
You're gonna have an agent along, hopefully, or you know, AI to help you troubleshoot that failure.
So that said, I've dealt with enough failure in my lifetime with technology.
Yes, you want someone that understands how it works.
Uh maybe there's another analogy here with automobiles, right?
Uh, I certainly don't know how to fix everything in my car, but I can take it to a trained mechanic.
And so maybe maybe there's something to that.
Yeah, but I guess if you're the engineer on what, you're the mechanic, so you still gotta know.
Um a lot of people say, let's, you know, we don't care anymore about the internals.
And the agent just needs to know, and we just need to ask the right questions.
But it's hard to ask the right questions if you actually don't know what you need.
So that that's definitely challenging.
So I would say that's almost the AI needs to keep us able to understand when the failure happens.
There's a concept called the moldable exception that actually adapts itself to show to the engineer to explain what it did in in their terms, in their understanding, not like how it was built.
And and that's kind of an important feature of kind of showing and learning from that.
And besides that, I often make the analogy between we we've done like years of automation in DevOps.
Um, you know, I think it was John Ospo who said, like, okay, you have your build system and it works, and you automated that, that's great.
And then it's been working for let's say six months, and then it fails.
And nobody knows anymore like how to fix it because we haven't done this enough.
It's a little bit where the field of chaos engineering came in, uh, kind of inducing errors and failures almost like a fireman that have to train and still understand.
So we might have to almost like train more to be ready for when it fails.
But again, it's a risk game.
You don't do that.
It's okay if you're not investing to that if your risk is low, but if it's high, you have kind of need to be ready when that happened.
And that's kind of the analogy that I think is suitable in this.
Yeah, I think I think the other thing that's true is like we've always had specialties as well, right?
Uh, if if there's a certain class of failure in the application that I built, maybe it's a networking failure.
I don't know anything about networking.
I I can't solve that.
I'm gonna have to go to a peer who's the network engineer, right?
That's that like that's been the story of engineering forever.
It's it's rarely an individual sport, it's nearly always a team sport, right?
And we saw that with with DevOps, right?
Like uh software engineers that have no idea how the production infrastructure is configured, and maybe a system administrator who has no idea how that code came into being, but can troubleshoot everything about the infrastructure.
And so I think we'll continue to see sort of that that specialty being required, and we'll see specialist agents that come and support each one of those roles potentially.
Yeah, it's interesting you said that because you know we also we always used to think of platform engineering as a tool to reduce the cognitive load, you know, in in many times in many times.
But now is the platform's job just to feed context, you know, again, pun intended in this case.
Um, you know, is it more of a knowledge graph than an infrastructure now?
I mean, what what is a platform anymore?
Wow, that's a wise question.
Yes, it is.
Uh I mean, I do think, I do think to your point, like you want the AI is going to give you better solutions when it has better context, right?
And one of the things that Dora researched and published last year in 2025 was the Dora AI capabilities model.
And two of the capabilities there are having strong internal data platforms and making sure that the LLMs have access to those platforms.
So maybe that does become certainly part of the role of a platform is making sure that our data inventory, like we have good, well-connected data, and that that LLM has access to that data, which includes, you know, obviously data, but also things like policy.
What are our compliance or security regulations that we have to follow?
Let's make sure that the LLM has can see that as part of its context.
And I think the platform team, uh, and and in fact, a strong internal developer platform was one of those capabilities as well that unlocks AI.
That's how you scale it across the organization to go from you know, this team or this pocket of engineers over here is having a great time with AI.
How do we make sure that we're seeing that across the entire organization?
But I do think if you think of a traditional platform team, they provide kind of more infrastructural pieces or services these days.
Like, yes, they can provide the LLM and they can provide storage for your context.
But the the I think the challenge there is who's gonna actually maintain the knowledge across the whole org?
Like that that's that's kind of the role.
It it's not is it's not in the data people right now because they're kind of like deeper, uh, and and kind of making sure it's consistent across and who kind of learned from all the things that that people are doing.
Imagine you have all your coding sessions.
How do you connect them together that like you know, if five developers hit the same issue that actually were serving uh this as this is a piece that's missing in our context, and we need to improve that.
So kind of that like new sort of knowledge observability across the agent's context, that that's that's a fascinating new role.
And is it a platform?
You know, there's platforms all turtles down, right?
Uh, but it feels like a new layer and a new kind of flow of data and knowledge.
I like that.
Knowledge, observability.
Yeah, yeah, yeah.
Yeah, absolutely.
Yeah.
Um, so you know, Nathan, you already kind of touched on it, but uh Dora looking more at like developer sentiment, well-being, um, mental health, those types of things.
Um, how do people avoid it going from code toil to review toil?
Hmm.
Boy, how do you avoid that?
Uh well, I think you have to avoid it intentionally.
Uh so you have to you have to like build the right systems in place.
In fact, I I would say that um if it well, maybe this advice isn't good today, but certainly two years ago, as you were just starting to think about let's bring some AI into our software development lifecycle.
I would have encouraged you to start with having it do code reviews for you.
Don't start with it having write code for you, because maybe you don't trust it yet.
Build some trust by having AI do code reviews.
Now, it's not going to replace the human code review, but it will be the first pass on that code review.
And that the the thing that is absolutely obvious about AI doing code review is it will get to the code review much faster than a human will every single time.
Uh, and it will be a comprehensive code review.
Now, it might not catch everything, you probably still want that human code review, but I know for a fact, uh, in just in my own daily work, I've done pull requests that an agent has code reviewed, and it has caught things that I can virtually guarantee a human would have missed.
Now, these are small things like a a typo, a misspelled word here, but the agent caught it, and I know that a human would not have seen that.
I would say there's probably a spectrum of people doing coding.
Um there's people who kind of say, give me a ticket and I'll solve it for you.
Or there's people at the other spectrum is like, okay, I want to build the best system and I want to get like value to the customer.
I would say if you're in the last one, it is so addictive.
Even if you get like a lot of pull requests, you just want to get it out.
You just want to make it better.
Like you it's not a chore, it's actually almost like addictive, similar to the TDD loop, like, okay, can I get it out?
Do they want that?
Do they want that?
So the it's it's very uh it can be very exhausting as well, but it's not a chore.
And for others, it is indeed like a chore.
So it depends on where you are, I guess, in the spectrum, uh and what's your passion?
Are you really caring about the visitors value, or is your job like, okay, I like to code, but like, you know, the syntax is important to me, and that's why I'm like really annoyed uh with all that AI coming in.
Yeah.
So Patrick, you've been quoted as saying expertise becomes the differentiator in a world where AI can handle the syntax.
I don't know if it's a correct quote, but uh in a world where AI can handle the syntax, what specific skills should people be looking at?
You know, if they're the listeners like just they're junior engineer or whatever, what are the skills that they should be looking at to, you know, make themselves more marketable, frankly?
You know, it's the skill to learn.
Um and it's it's similar to uh I don't know what the uh kind of US terms or English terms are, like educational system, but you can have a very practical education that says like how to do one through three, or you can have a broader education that actually says like think about the problem and like problem solving.
And I think in this case, you're you need to drive the AI.
So it's it's more at the layer of having problem solving, figuring what you want versus the actual thing.
And that's it's a skill you can learn, uh, but it's probably more valuable uh with this new work than it was in the past, where they didn't let you kind of take the time to actually figure it out.
Now it's almost part of your loop to figure it out.
So which I kind of like.
Yeah, I definitely I definitely agree with that.
I think I think the other thing though, um that is true today is that when AI generates something for us, whether that's code or an email or a document, the people that are in the best position to evaluate the efficacy of that thing that it just generated are the people that understand, right?
The people that know the code, like know, I don't know, whatever framework you're working in, know the idiomatic way of writing that language.
You can look at what the AI has generated and determine is that idiomatic?
Is that following best practices?
Is that right?
So an expert is gonna always be an expert evaluator as well.
And so with that, I think that you know, a junior engineer or someone who wants to write a lot more software, whether it's them that writes it with their fingers, or they use you're using an AI agent to do so, I think one of the things that's always been true is the best way to become a better software engineer, a better coder, is to read more code and then write more code, but reading over writing.
So just go read more code and and and be able to evaluate is this code that the AI has given me, is that slop or is that good code?
And and and try to build up the intuition for that, because I think at the end of the day, that's really what it comes down to.
There's an interesting uh thing happening in a way that if you would ask, like start from a blank slate and you ask like 15 engineers, go writing, and they're all kind of like, yeah, but I think we should do that.
And it's almost like inhibiting them from actually writing any of the code because like it needs to be perfect.
But once somebody has written, they would all argue like please shame this, please do that.
It's the same thing with writing a blog post, like doing it from a blank slate is hard, but then kind of correcting something else.
And that's also quite interesting use of an AI.
It's like this is the first seed, and then you adapt and you adapt.
But you didn't have to kind of go for like the first boilerplate, the first thing to go there.
And uh, you know, if it gets it wrong, you're still spending a lot of time in correcting it, but that's again uh seems to be getting better, and and less and the more context you give it, the less time you spend in that as well.
Yeah, and one of the best ways to to end those arguments over like let's just tweak this, tweak that working code wins.
So is this code from AI?
Is it working?
Is it doing what we expect it to do?
Great, it wins, at least it wins for today.
And we'll adjust it over time.
Like it's it will always be an iterative practice.
I don't think any of us expect to write a line of code and have that line of code running for 20, 30, 100 years.
Now, unfortunately, it's true that probably code that we wrote 20 years ago is still running in production, but that was definitely not our intent at the time.
But I I had like an interesting week just we had a new new launch, and it was very hectic, right?
Like it's like typical launch as it shouldn't happen, releasing features uh at the last minute.
But like everybody was kind of giving feedback, and the usual flow would have been create a ticket, there's some triage, and we're gonna pick it up.
And what we just started doing is okay, here's a ticket, brief chat on Slack, and then okay, please AI bot, build a PR.
Let's review.
And like it wasn't waiting until somebody picked it up.
It was like instantly in the chat, having that like approval.
Okay, release.
And and and that's just an insane feeling to to see the speed at which you can s ship things.
And I was writing docs and I was not looking at the code, and I was constantly asking my AI like, is my documentation in check with my code?
Is it in check with my code?
It's like it's I couldn't have done this in that close and speed loop uh without DAI.
And it's just so powerful.
And while I understand all the limitations, I think it's just here to stay to to make us better.
So this is going to be, well, I think most of my questions have been, but this is going to be a very leading question.
So I'm a CTO, I'm a VP of engineering, and I'm whatever.
Um, I mean, the the easy answer is oh, be intentional.
But how?
How do what do organizations do to keep their people upskilled?
I mean, does Slack time play into it?
That's where it's leading, because I think it does, frankly.
Uh, but you know, where what are the the concrete things that a manager listening can do to make sure their teams are allowed to keep up?
I think it's pretty easy.
You just buy the licenses and then everything works.
As always.
Says the Google person.
You have licenses.
No, obviously, you have to like there are a bunch of things that have to happen.
And and one of the things uh that I think is truer than it's been probably in my entire career is that things are moving so so quickly.
And so I do worry sometimes that organizations are gonna rush to standardize their tools and their workflows, and by the time they standardize, they're gonna be six, twelve, eighteen months behind what's state of the art today.
And so I think that to your point, like we have to build in some additional Slack.
We have to adjust the expectations that we have on our engineering teams to allow for that Slack.
And how do you fill that Slack?
It might be hackathons, it's definitely time to experiment and learn and share what we're learning with each other acr across maybe an internal community of practice, something along those lines.
I think that's super super important.
Yeah I think as a manager you're an enabler there so anything you can do on removing friction limiting it to one tool it doesn't work in this chaotic period.
So you'll have to kind of approve multiples and allow people to play with it.
You gotta you can have like rules and and grant rules to what apply where but you gotta give that budget it sounds like weird and we don't have unlimited budget but it definitely helps in kind of like not have to think about tokens and spending while you're experimenting.
So that's that's again another thing.
And then it's it's almost like rewarding it like bring out the cool stories what people did bring in external expertise bring in external stories the learning but I think the best learning is actually doing it in your day-to-day job.
And that's so if you're allowed to do that if you have a process in place if you just have a few champions that you get going, uh, I think that's similar to any change in an organization, whether that was DevOps or Agile or or anything, you find the champions, you nutture them, you kind of remove the friction points, and then you kind of like start building that like a community practice.
Now, bear in mind whatever you think is now good will be outdated in a couple of months.
So it is revol uh evolving in a way that we're thinking about the problem different, about the solution different.
Uh and and that's normal in this chaotic maturing uh period.
Um this is probably the faster that has happened in ever in the industry, where in the possibility we had some time to absorb this, but now it's so fast, uh, and that's why you gotta start today to do it.
Yeah, I just want to add one thing to the managers there.
You said the the manager should help bring out the successes in the same way they should be celebrating the failures.
Something went wrong, let's talk about that openly so that we can all learn as much as possible from that failure where the AI took a misstep, where our context wasn't quite right for the AI.
Whatever it was, we're we learn a lot from failures, and it is a like it can be a huge waste to sweep those failures under the rug.
We want to learn from them and amplify those lessons across the organization.
I mean, there was a huge study at Google, gosh, might be close to a decade ago now, that said that psychological safety was the number one indicator of a successful team.
Has that changed?
The ability to talk about failures?
Is that I think that's the same thing.
I think it's I I I would agree that it's the same, yeah.
So also, what role does corporate policy have here?
So, like Google talks about clear AI stances as opposed to chasing the latest LLM or whatever.
What role does corporate policy have in in helping here?
Yeah, in our research, one of the things that we found, as you said, is that a uh clear and well-communicated AI stance is important.
Now, Dora doesn't weigh in or have a strong opinion about what that stance should be, other than that it is clear and well-communicated.
Because what we find in our research when it's not, is that you have people that are maybe using some AI that they're not sure if they're allowed to.
And that adds some additional friction and stress onto that worker, right?
They're maybe delivering more, but maybe they're doing it in a way that they don't feel super good about.
The policy has to be uh, like I say, clear and communicated.
Hopefully, it's not thou shalt not use AI anywhere in this organization.
If that's your clear and communicated policy, uh I can almost guarantee that someone is violating your policy.
So like yeah, you have to be a little bit more open to that.
To Patrick's point, though, I think that you know, there has to be maybe it's not you can use any tool that you want, but we do have a collection of three, five, seven different tools that you can play with.
And let's go learn from each one of those tools, and eventually we can start to converge, but today is not the time for convergence.
Yeah, clarity is uh important in that case.
Um but there's a certain level of experimentation that you will never capture with clarity, unfortunately.
Yes.
Um and in a way, if you make it too broad, it feels bland.
If you make it too specific, it becomes narrow.
I'm not like the policy writer, but it is an art to get that balance right.
Absolutely.
Absolutely.
I mean, so I mean it feels like we've spent decades trying to make software more predictable.
Should we just give up?
Is it to just understand that it's a complex adaptive system and we just need to constantly evolve with it?
Is or is predictability still hopeful?
Or are we hopeful for predictability?
Put it that way.
I think it's two different things.
It's uh making software more predictable, I think is still a goal, but again, within the limits of the risk appetite, whether you want that or not.
Um and then the delivery process itself has also a certain predictability, but that might also change in a way that like we might not care about certain features as we did in the past, and we care about the the other features we uh now.
So that kind of balancing act is is uh still going there.
Yeah, I I I would agree with that.
And I think that you know, as as we're starting to accelerate our ability to do things, that gives us an opportunity to remember why are we doing these things.
We're doing them for the users of the applications that we're building, and and maybe that gives us some time to get even closer as an engineer to what is it that the user'sers trying to accomplish.
So, like back to your idea of like this user vibe coded a solution on top of my application, that's an amazing form of user feedback that I can now do something with.
And I I think allowing engineers to get much, much closer to that actual problem that we're trying to solve.
I think that's really really important.
Yeah.
In in my four patterns of AI native dev, I I said we're a developer is becoming a little bit of an ops, a reviewer, like what can go uh into production.
They become a little bit of a QA by saying, here's my requirements, here's my intent.
They become a little bit of a project manager, product manager by saying, actually, I've tested it with users, and this is actually the business value.
And then they hopefully got our data as well.
So they become the data analyst.
Now, good engineers don't stay in their development lane.
They learn that they actually need to go across the other boundaries.
And I think AI is helping us as the engineer to do that.
And bear with us because the product engineers are coming into the coding space, the QA are coming into this coding space.
So we're all kind of like changing and uh the lines are blurring, but it means we're overlapping also in the domain and can help each other kind of uh close that.
Yeah, and maybe the bots that are always on can help us start to explore those other domains a little bit more, right?
Without putting a burden on my peers, I could put that burden onto the AI as I go and explore that other domain.
And and and then frankly, I can ask smarter questions to my peers, my human peers in the organization.
Even more questions?
Um, for a closing question, uh, for I'll let each of you individually, um, you you all live in this every day and talking to different organizations and what have you.
Uh you know, so I'll start with you, Patrick.
What's something I did not ask you that you wish I had that you want people to know?
I think the focus right now is still too technical.
And it should be my opinion around the knowledge management.
So it's probably within a year or two.
That's the only thing we're going to talk about, in my opinion.
Nathan.
I think that um uh just just going back to the whole amplifier metaphor.
I think it's really important that you understand how your systems work today, and then make a decision.
Are we here to augment how those systems are working, maybe to improve those systems, or are we here to radically change and like think again from scratch, how are we going to build up these systems and these processes?
And that that goes for something like software delivery.
Are we going to improve our current software delivery process, or are we going to uh reimagine a brand new software delivery process where we don't have any constraints?
The answer is probably yes in your organization, but you have to be intentional about where are we doing which one of those things and and and then that probably comes back to your risk appetite.
Okay.
So I want to thank you both for taking the time.
Uh I know that Patrick just came off of a very long flight, and and Nathan just came off a shorter flight, but still not short.
Um so thank you very much for your time both.
Thank you, Ken.
Absolutely.
It's a lot of fun, Ken.
Thanks.
Good.