# AI Software Loops and Context Engineering Strategy

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-09-17

## Transcript

Hello, everyone, and welcome to another edition of the ThoughtWorks Technology Podcast.
My name is Ken McGrace.
I am one of your local hosts, or one of your recurring hosts, I should say.
And I want to introduce a co-host today that those who are regular listeners have heard a little bit lately.
We've had them as a guest on a couple of episodes.
And we're pretty happy with knowledge and everything else.
And so invited Kerr Sanders to join us in the hosting panel.
And Kerr will be joining us as a co-host for today.
So Kerr, do you want to do a quick intro again, please?
Of course.
Thank you, Ken.
So hi, everyone.
I'm Kara Sanders.
I'm a principal product engineer at ThoughtWorks, and I've been here for about a year and a half now.
My background covers a range of things, distributed computing to AI systems.
Luckily enough, I've been building AI since before AI was in the mainstream, so it's very interesting to watch it transform.
Great.
And then for our guest today, it's kind of interesting, at least to me.
One of the things that I like the most about ThoughtWorks, and I've been here, I wasn't gray when I got here and I am now, but I've been here for a little while.
One of the things I always thought was really cool was the way that we at least try to build a culture where people are learning and testing boundaries.
And then often, you know, it's a double-edged sword, they go off and start their own thing.
We have a long history of that, all the way back to Selenium before I joined to continuous delivery when I joined, microservices and data mesh, et cetera.
And AI is no different.
And so what we have here is a couple of their former thought workers.
And so I hope we can take at least a little bit of credit for their experience and expertise.
But I'll let them introduce themselves.
First off, Cassie.
Hi, everyone.
My name is Cassie Shum.
And as Ken just mentioned, I was a ThoughtWorker for about 12 years.
So absolutely, ThoughtWorks gets a lot of credit for a lot of the foundations and things that I've learned over the years.
essentially has brought me to where I am today.
I think after ThoughtWorks, I joined a startup called Relational AI, where we focused on a lot of knowledge graphs and the context layer is a lot of people are talking about right now, which I believe is very applicable to the new AI agentic world that we see ourselves in.
So yeah, no, I'm super excited to be here.
Thank you, Ken and Kerr, for this invitation and excited to chat about what AI means today.
Cool.
And Tim.
Hi.
Yeah, my name's Tim.
I've also been at ThoughtWorks for a very long time, for 19 years.
I like to say that I grew up at ThoughtWorks.
I learned my craft through lots of pair programming and TDDing for many, many, many years.
Last few years, I was at Amazon working on AI adoption and AI native transformation.
But in general, just...
a big interest on um developer experience and developer effectiveness and that's what's what's driven somewhat driven to what what i'm focused focused on now cool um so what we want to talk about today a little bit is the idea and we've covered this before but i think cassie and tim have um a little bit different take on it of you know how teams need to to behave differently we need to not just add AI to the bolted onto the end of our software development, but the actual way you create software is different.
A term that we're seeing a lot these days is loops.
You know, ThoughtWorks has written a little bit about it.
Cassie and Tim have talked a little about it and so forth.
And so I guess first off, you know, they're saying, okay, every team already has like a product loop and supposedly an execution loop.
What's all the hubbub about loops?
What are we really talking about here?
I think loops is our next generation word for, you know, how do we close the feedback gap, right?
Like, how do we learn from what we're actually doing?
And so when we talk about product and execution loops, they are very much the STLC process or the PDLC process that we saw from years ago, all before AI.
So I think that's...
That's number one.
Like, that's, we're bringing that back, right, as a first class concept.
I do think, and I'm excited to hear Tim's opinion here as well, because we've been kind of focused on both of these loops, is that...
As engineers, we are seeing in the enterprises and companies right now that there is a major focus on the execution loop, right?
So there's a lot of software factories and harnesses because there's the agentic technology that has come about in the last couple of years has really accelerated that.
And so I think the major focus of that.
has been accelerating, right?
But one of the things that Tim and I have discussed at great length, and we're trying to work with our customers on what that actually means is it doesn't just stop from the spec to the PR, right?
So how do you close that loop from a value sense?
How does that actually come back to the product?
And that's why we talk about the two closed loops, and they're both equally important, and they need to feed off of each other.
Definitely agree.
I think what's interesting is that they're optimizing completely different ways, right?
I think from the beginning of software development, we've always wanted to sort of industrialize software development.
But it's kind of been difficult because most of the time we're actually creating something that's new and novel.
But I think now, especially with AI and some of the insights that we get from agent traces and things like that, we can be explicit about these two loops where Actually, you know what?
We do actually want to create a software factory or a dark factory.
And we do actually want to industrialize things that are concrete and deterministic.
But there's a lot of software development that is not concrete and deterministic.
And those things we actually need to sort of like acknowledge and accept that they are fuzzy and they have to be discovered and evolved and iterated on.
And sort of embracing that asymmetry between those two loops is sort of where we see the team working on.
So obviously right now there's a ton of focus on improving agency efficiency and creating harnesses and that's all great, all in the execution loop.
But we also want to use the sort of impetus of AI to actually close the gap between product and engineering.
Because right now developers don't have to spend two weeks to build a feature.
They can actually...
come up for air, you know, after like half a day or a day and they can maybe collaborate a bit more.
So that's more about like why we're sort of thinking about these two loops.
And one last thing to add on this one as well, and Tim and I have discussed this a lot because we've been hearing this from actually some of our previous places that we've been is...
that because now the agentic life cycle is up in front center and everyone says, let's bolt on the AI, there's such a focus on spec writing.
Like, how do we actually hone in that spec writing so we can hand it over to the agents?
And as I do that, I feel like I'm saying, how do we make things more waterfall?
Like, I'm going to upfront design specs and then the agents will take care of all of that.
And so I always ask people when we're talking to them, I said, When have you ever had an idea that was that same idea at the very end when it's in front of your customer?
And half the time, if not more than time, they said, oh, no, it's not.
Because going back to some of the fundamentals that we've talked about for years is like you have to iterate and learn on that idea.
And so the question now begs is how do you do that with the agents?
How do you do that with builders and agents and iterate that and create a system to do that?
And so that's why.
Those two loops are incredibly important as well.
We don't want to be the new waterfall.
We want to actually embrace that collaborative approach of actually creating an idea and finding value in that using the agents that we have now.
Is it the same problem frame differently?
Because if we think about the DevOps movement, what, it was 16, 17 years, that was all supposedly, I say supposedly because it got hijacked a little bit, about feedback loops.
and making sure that product teams were seeing how things run in production, they could react faster, you know, and et cetera.
Is this the same problem with different clothing or is it really that different because it's AI involved?
I would say it's absolutely the same problem.
I think what AI, and it's, you know, what old is new and all that kind of thing.
And I think it's really what AI is doing is accelerating, right?
And, you know, the promise of agile or the dual track software development, we've always wanted to have this close collaboration and this feedback.
And yes, it's just kind of like embracing that and just because of the acceleration of AI, I think.
I think that acceleration is going to expose all of the different bottlenecks in the software development lifecycle process.
It's not just engineering anymore.
And I'm going to humble brag Tim a little bit.
So five years ago, he wrote about the developer effectiveness.
You know, he wrote on Martin's blog about how to actually hone that in and make that more effective, right?
And so he talks about the bottlenecks that developers faced back then.
And I think now we're in a new phase where new bottlenecks will come out because agents and AI is accelerating, if you do it well, like accelerating the engineering area, right?
The developers, the friction that was held and felt for many decades.
And now...
we're going to find the friction and the bottlenecks in other areas as well.
And so I think the premise of the feedback is the same, but the bottlenecks is going to appear in different areas, Tim.
Yeah.
And you sort of give some examples, right?
And some of this may come down to the fact that we have more data, right?
How do we understand developer sentiment?
And friction, historically, it was through surveys and pairing and things like that, but it's very difficult.
A little bit with AI, and because we have faces, you can ask Claude.
You can actually go to Claude and say, oh, the last two weeks, how did I coach?
What was I doing to coach the agent?
You can get all this kind of insight that you couldn't have done previously.
And I think a lot of times with developer experience, there was this kind of like hidden work that nobody knew about, that the developers were doing and getting frustrated about and was not very obvious.
Like examples might be the sort of hidden validation layer.
You might have the most amazing test coverage, but to actually, did this software actually work?
A lot of that was fairly manual.
And I think we're now actually, through sort of optimizing this execution loop and measuring the amount of manual coaching and interventions, we discover these weaknesses, like in our test permits and things like that.
And so I think hearing this, one of the questions I have is we talked a little bit about...
the difference between these execution loops and the product loops.
And the execution loop, it sounds like, you know, is that spec to PR below, making code, generating it.
What do you see as the product loop, the other side of that?
That's a great question.
So I think some of the work that we're working on in terms of the product loop and bringing some of the agentic AI framework into that.
is really about two things.
One is, I would say, bringing the context that, say, the engineering teams have originally had for a very long time and bringing that closer to the product loop so that the ideation, the things, the hypotheses, and the product feature thought process is actually grounded in sort of the tech estate that your organization is grounded in.
And so I think one of the things that is very powerful now is that we can have business owners, product managers, people who have these really wonderful ideas and developers, like bring the ideas to bear with a shared context that you can bring in from architecture standards, how the different tasks are working out.
the different repositories and things like that.
And the reason why we can do that is we can pair with the agents who can actually siphon through all of that information very quickly and validate whether this hypothesis is doable, for instance, or shape it in such a way that it's now removing sort of...
the toil and churn that goes back and forth between product and engineering historically, right?
I remember back in the day, a product manager would say, hey, this is a great idea.
And an engineer would be like, oh, you can't do that.
Not in this ecosystem, right?
And I think even on the smallest sense, you can actually start collapsing that a bit in this agentic framework and really collaborate a lot more given you can have a shared context with the agents.
A couple of interesting things.
Part of what we're trying to do here is almost empower the team a little bit more, right?
Because I think, like intentionally or unintentionally, sometimes with development, you just have so much work to do that you don't have the capacity, even if you are empowered, to understand the customer or look at the product strategy, product metrics.
And I think if we can kind of bring the team together a little bit more, because if the promise of AI holds true, developers have more time.
you know, technologies have very good ideas, but they have to have the information.
They have to understand the customer, those kind of things.
So I think with having these two loops and having like things like, so it can be like very simple, right?
Like having an idea registry or like somewhere that you can have an idea and that product and developers can work on it.
Because at the moment, like the constraint isn't so much about building it.
It's actually...
Is that idea worthwhile?
Will customer, what's my evidence behind that idea?
Why do I think it's useful?
Because, you know.
You did bring up an interesting point, maybe unintentionally, Keir, which was around the execution loop and the pull request.
I think this is a very interesting point, and because I think a lot of AI is measured on pull requests at the moment, and with the execution loop, I think, you know, it depends on the environment, but ideally...
We try to measure until it's actually released software, I think.
Because I think it depends on the setup, right?
Like in an audio situation, everything shifted left and your PR represents something that is releasable.
But that is not the reality at a lot of companies, right?
A lot of companies, there's a lot of work that happens after that or request.
So I think part of that execution loop is actually understanding what is happening after, right?
And so whether it's like a manual queue.
Ken, this is all DevOps.
There's all classic DevOps, but if it's a manual QA team working on it or whatever kind of slow end-to-end tests, let's just move all that shift left.
It's funny that you mentioned DevOps because I think a lot of the challenge of the DevOps historically, for me at least, was more organizational.
It wasn't even the technology.
It wasn't anything.
It was just how people were structured.
Conway's Law in action.
And so I wonder with these different loops in AI, do you think it is?
an AI issue or do you think it's more of a rethinking how we work issue as teams?
I think it's more of the latter, the rethinking.
I guess what we're trying to be is like, maybe we're just moving too fast into this next phase, right?
And we don't really quite understand what is productivity anymore because as a developer, how do I become more effective?
Should I be measured on the amount of agents that I command?
And my goal is to command larger and larger swarms of agents that produce more and more PRs.
Or do we have this opportunity to, as you said, actually use, it's almost like using the impetus of AI, right?
I think everybody at the moment, lots of folks are open to change and rethinking the SDLC.
Yeah, to actually.
really think about not necessarily just software development, but product development, like how we're doing it end-to-end and how we're thinking about team structures and how we're bringing people together.
So absolutely, I think it's about the org transformation and those things, yeah.
So a phrase I've seen, I believe it was in one of your writing, and it may have been on your website for your new company, was the idea of a connective layer.
I think that's where this differentiated, in my head at least, from all the other talk about loops.
Was I hallucinating or what is that?
Yeah, maybe I can jump in here a little bit.
I think the connective layer or another frame for it is the context graph or sort of the layer where the two loops sit on goes back to actually very, very much organizational things that we have seen in the past.
But now...
we have the opportunity to bring some of that organizational knowledge into these loops, right?
So I'll give an example, like, of something that's happened before and then what we can actually do now about it.
So I find that...
Before, you know, as all of us engineers, product managers, we go in and we're like, we need to build a product, right?
And so where do we go first to understand an organization?
We go into the wiki.
We go into the Confluence page.
We look at the architecture diagrams.
We go and talk to the expert on the ground who has a tribal knowledge just to actually go into that repo and then go into this repo, right?
So a lot of the things that we practice in terms of collaborative, you know, team energy, like...
in the organization to build good software is to gather that collective knowledge.
But we did it very ad hoc and we had, you know, teams that knew certain things and you'd slack someone here and slack someone there and things like that, right?
And we're not saying move away from that, but there are some...
things now where when we have agents and AI that, as Tim said, is accelerating everything.
Imagine in an organization that an agent is now going into all of your wikis as an organization.
And if your organization is 20 years old and you have a lot of knowledge in that wiki, how do you know what is the truth, right?
Like that agent is not going to decipher what is true now versus what was true five weeks ago versus what was true two years ago.
right?
And so now we get a lot of different types of knowledge that we can't make sense out of.
And so how do we actually create software on all of that knowledge, right?
So one of the things that we talk about is sort of this connective tissue.
And this still takes collaboration with the teams to understand what is important in your organization.
Is it these architectural standards?
Is it these testing rules that we need?
Is it these domain bits here that actually make sense?
And that's what we're moving forward with.
And it's also like, what is in play right now?
What stories are actually being developed now?
What was blocked?
And all of these kind of things.
So I'm talking about sort of this organizational knowledge within your software development team.
that can now be collected as sort of a first-class citizen so your agents also have that priority in terms of how to build these things.
And so that's, I think that's what we need about the connective tissue, and that's just as important because of the context windows that these agents have and the lineage and all of these kind of things.
So how do we get people to actually participate in that?
You know, I mean, you know, again, and I'll be honest, I'm playing devil's advocate a little bit on purpose.
You know, we've had knowledge management type stuff forever.
And if nobody writes it up, then it doesn't get in there.
And, you know, part of my job is like reviewing, you know, blogs and technical writing and that sort of thing.
And people are out there doing.
AI based searches and they're finding marketing material and assuming that's from someone's real experience and they can't wait it, you know, all the way to, um, and I promise I'm not trying to be an AI naysayer, but this actually true story for some reason that defies logic.
We have two puppies under the age of 16 weeks in my house right now.
And I asked one of the team, I said, how many weeks old is, his name's Mongo.
How many weeks old is Mongo?
Because I didn't want to count weeks.
That's what the vet wanted.
It gave me an answer.
I said, okay, and how many weeks is George?
That's the other one.
They gave me an answer.
I'm like, wait a minute.
Mongo's older than George.
You got these, these are backwards.
What the heck is, oh, sorry.
I mean, if yesterday, the latest version out of insert vendor name here.
Couldn't count weeks properly.
Can I really trust it to know which context matters?
You can trust the answers that come from your agent based off of what you give it, right?
So that priority is that context layer that you, the SME, need to actually feed into the context, right?
So one of the things that I find a bit troubling with a lot, and I fell into this pattern myself, right?
Because it's easy.
It's like I'm talking to my agent.
I'm like, oof.
My agent knows a lot.
And so you learn to trust.
You learn to trust everything that comes from it because it is grabbing from multiple sources of data that you can't even read fast enough, right?
But I think one of the things that we've all seen in the past year or so is that we get a lot of AI slop.
We get a lot of hallucinations.
We get a lot of things because the data is not curated for that particular agent.
The way we're thinking about it is to just turn it around and say, how do you have specific agents that you're feeding the context that you care about so we can make the right decision, right?
And then the biggest part that I know Tim cares about a lot is then how do you verify?
that those agents are coming up with those right answers based off that context that you've given.
Yeah, of course.
It's a massive problem, right?
And it's always been this problem of documentation drift.
And we can't magically solve it with AI, but there's certain things that we can do, like a lot of documentation.
You can detect documentation drift for your legacy systems.
And I know there's lots of innovation around generating quality information about an existing system.
And I think what we're trying to do is almost like, or what I think the best practices is kind of make it easy to bring in that sort of relevant quality information, right?
Like, I mean, one big thing is like when you have a feature or something, do we know the intent of it?
It's not necessarily the requirements.
Do we know the intent and what do we hope to achieve?
to change when it's out there, right?
And because often sometimes at some point somebody did that, right?
When they were imagining it, but it doesn't make it to the development team sometimes and it gets lost along the way.
So those kind of like, I think you can create tools that allow this collaboration where those kind of things, that lineage is actually captured and that helps the AI, right?
That background will help the AI and the developer.
So many questions I want to ask, but I think one of the big ones I have is, you know, my team is right now, we're working on business intelligence systems.
And so you can imagine business intelligence systems means ingesting a lot of business intelligence to do that and validating it and making sure it's right.
And I wonder, considering there's this context layer that you might be building to support these different loops, how are you thinking about supporting people bringing their business intelligence to the platform in a way that's scalable and doesn't require a fleet of forward deployed engineers to do it for you?
Yeah, I mean, I would say there's a lot of innovation in this space.
I think there's a lot of tools that will help you clean and identify information.
I mean, some of it like, because some of this comes down to how do I know if information is right and high quality enough?
And also efficient, right?
Because, you know, an agent can waste a lot of tokens just reading through reams and reams of things that didn't really care about.
I think it's relevant for certain types of information, like maybe architecture documents or coding standards and things.
But I think benchmarking is a useful activity because especially when you're benchmarking your harness, a lot of what actually improves whether you can complete a task or not is the information that feeds into it.
So it's sort of historical benchmarking because that's a combination of the context, your skills, your MCP tools and your tests.
I think that's something that can help.
Cool.
Kerry, do you want to ask any more follow-ups there?
You know, one other one I had.
It might be too early in the conversation, so we'll see.
But we talk about context engineering and building this shared understanding of the product loop and the engineering loop.
And my mind goes straight to multiplayer AI and the whole issue of how do we have teams of people collaborating on these context data sets with these agents.
Let's say you have an agent or a citizen that's AI-driven.
that two or more people are using and collaborating on simultaneously.
So it's not like it's just one person talking to a chatbot in a room by themselves, but it's more like three people talking at the same chatbot at the same time.
Yeah, no, I think this is actually quite key in terms, and we'll see what the future holds for this, but I would say that having multiple people talk to one agent is one interesting example.
And I would say that having that shared context, It sort of doesn't matter if that agent is the same or it's the next agent.
If you have the source of truth as that context and then the agents are actually playing off of that one, then I think that would work in future.
I started thinking about your question in terms of like...
what kind of different roles some of these agents can play, like these adversarial agents or this analysis agent, and what kind of skills are we decorating our agents with in order to drive out some of these best practices or even some of these collaborative practices as well, right?
So I would say, like, in some of the systems that we're building right now, we have, like, an analysis agent and a spec writer agent that...
is about discoverability and thinking about what the hypotheses look like and then working with yourself and myself together to sort of, you know, come up with the best type of hypotheses to really drive out some of these acceptance criteria and stuff like that.
And then, like, in another sense, I would say there's another agent that's decorated with...
I want to challenge.
Is this actually going to bring value?
Is this actually going to do this?
Is they're going to do that?
And I think that tension, even between the agents and us humans, is needed in this collaborative sense to what Tim said earlier is around like, how do we bring the best value to our customers or in the software at the end?
What is the actual intent here?
And so what we're trying to think about is not agents replacing what we're doing, but enhancing.
that higher level thinking that makes the software what it is, right?
That's what we're here for, right?
So I think that's the way I want to, you know, change our thought process in terms of the way we collaborate and the software gets built.
So one pattern I've seen that I find interesting, and we're seeing it ourselves too, is, you know, consultancies get out there and can see these things and recognize them, sometimes correctly and sometimes not.
and are rarely positioned to offer products to the space.
And you both talked about multi-years at ThoughtWorks, and we used to have products.
That guy used to work for that division.
But mostly as consultants.
What led you to believe, whether it's rational AI years ago or your current one that you're working on getting off the ground, where are products?
better able to solve these in a consultancy or what led you to the product offering, I guess.
I'll give you my opinion of why I'm excited about building a product is actually something that I will put Tim and I on the board.
Like, I would say maybe nine, 10 years ago, we've been friends for a very long time.
And I remember over dinner one night, we said, gosh, you know, we keep.
talking about the similar problems that he and I were both facing, but we were on different customers.
And we kept seeing the same patterns and things like that.
And we said for a long time, my gosh, wouldn't it be really great to have these accelerators, to have these bootstrap things?
Like these patterns are known, right?
And of course, there's some bespoke problems here and there.
But at the general sense, we can identify those patterns.
And we've grown up in this world where...
We became very good at pattern matching, right?
And so I think like at least what brought me back to working with Tim again is that I remember that conversation.
And now in this world of acceleration and the two of us being able to accelerate putting these patterns that we already know together using agents was what brought us around to, I think these products can now accelerate this.
I wouldn't.
you know, over-index on like this product is the silver bullet.
No, I would say that these are the things that are going to accelerate AI impact for companies.
And that's how we should think about it.
I couldn't agree more.
Every customer is like, oh, but our problem is that unique.
And it's like, well, not so much.
How have your conversations been?
Are people like, oh, yeah, you're right.
We get that there's, you know, call it the 80-20 rule.
Call it whatever you want.
but that there's a lot of overlap here or is there pushback?
What's the, what's the responsibility?
I would turn it around less about more about the problem.
So I think most of the customers have the, have the problem, which, which is more around the, I mean, at a broad level, it's, it's, you know, not seeing the AI impact they expected.
But at more granular levels, it, you know, it is a lot of, it's about the, The upskilling, the changing of habits day to day, and how developers are dealing with this new world.
I think a lot of that is common.
So what should those of us who still live in the consultancy role, which is a large percentage of our listeners, if I'm honest, what are things that we could change or should be changing about our behavior to get people to recognize this more?
For me, I would say...
As a practitioner, lean in, lean in hard with everything that's going in with these agents.
And not to say that you need to be dependent on all of these things.
It's really to create empathy for the folks that you are consulting with, right?
So I will personally say that I...
I called myself post-technical for years because I was.
I was the architect who talked about design and patterns and things like that.
I've been very fortunate to have the opportunity to go back and actually code with these agents and understand what their limitations are, how you can actually use them as opportunistic enablers and things like that.
And I wasn't really truly able to conceptualize that until I was on the ground building with the agents and seeing what they can and can't do.
And then it's a flywheel because everything's changing.
And so to stay in that mode right now, I think it's incredibly important as a practitioner because that will just make you so much more powerful for your customers who...
Frankly, a lot of them are very scared.
That's what I'm hearing.
There's some fear from the engineers, practitioners on the ground is, is this going to take my job?
And the answer is, get in there and see what you can actually use them as an enabler versus as a replacer.
I really love the note about having empathy for consultants, users, for example, our customers.
Because ironically, I was something of an AI skeptic for a while.
And in some ways, I still am.
But the one thing I do...
is use all the models as much as I possibly can, only because using them shows us how good or bad they can be and gives us a real understanding for it instead of just hyperbole.
One of the things I had earlier, you were talking about silver bullets.
And I was thinking to myself, I like it when a product describes itself as not a silver bullet because it knows what you are best for.
And I'm curious from where you are right now, what do you think is the thing that you're going to be best for?
with this new concept of the different loops and bringing them together with a context layer.
I think it's about to bring the humans back into the loop in a productive way.
I think that's the differentiator here, right?
So we're not here to accelerate and get rid of everything.
We're here to actually utilize the humans in the way that we've been wanting to utilize in a long time.
So that's what I think.
Yeah, I mean, it's easy to say, but yeah, focus more on creating.
better products i guess rather than just more products better products i think that's what i want to be yeah sometimes i wish this was a video blog and not an audio blog so you could so the listeners could have seen karen i applauding for bringing the humans back in uh appreciate that um so the the question i like to repeat to every guest is a lot of this is informative stages and i get that but Is there anything you'd give our listeners, advice you'd give them?
You know, Monday morning, they come to work.
They're mostly practitioners.
You know, what should they be doing?
What's an actionable takeaway?
Is it go read a book?
Is it go do a thing?
Is it try another model?
You know, what should they do Monday morning?
And I'll go one by one.
I'll start.
I started with Cassie.
So this time I'll start with Tim.
So I think what I would probably say is like, slow down.
Like at the moment, there's like so much pressure.
to be producing more and more and more.
And I think, especially when we think about being effective, like I think when you get in, you know, with AI, you get bombarded and you're playing whack-a-mole with all the agents.
I'm blocked, I'm blocked, I'm blocked.
And it's too easy to get too much into that instead of thinking about, you know, if we come back to the sort of the execution loop, how are we actually...
improving our software factory execution so that it is easier to work with.
And then the other piece is being more effective is maybe actually see how you can close the gap to your product business stakeholders and think about, well, can we actually create, rather than just more software, this sort of better, more effective software.
Perfect.
And that gives Cassie the last word.
Man, that's a hard one to follow.
He stole my answer.
I would say very similar to Tim is what problem are you trying to solve?
So instead of just diving into Monday morning and spinning up all those agents and, you know, hearing that sound that.
Now it's just forever in my head.
I would say, yeah, like talk to your teams, try to figure out what problem are you trying to solve today, tomorrow, and maybe always take a step back and say, am I still solving that problem?
And how can I better leverage the tools that we have right now instead of just getting in the mode?
So, yeah.
Great.
So thank you very much for your time, Cassie and Tim.
Care, welcome to the jungle of being a co-host.
for our podcast and congratulations.
And thanks for the listeners.
Yeah.
Everybody have a great day.
Thank you.
Thank you.