# ThoughtWorks AIWorks: Platform Strategy for Enterprise AI

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

## Transcript

Hi, everybody.
Welcome to a special edition of the ThoughtWorks Technology Podcast.
It's going to be very, very short.
What I'd like to do today is introduce you to a brand new host that's joining the technology podcast going forward.
Very excited.
So please meet Ricky Zachary.
Ricky, why don't you introduce yourself to the listeners?
Of course.
Uh thanks, Ken.
Hello, everyone.
My name is Ricky Zachary.
I've been at ThoughtWorks for about five years.
Right now I'm the practice area lead for engineering platforms.
I'm extremely excited to join the technology podcast.
Uh primarily because I think that it's going to give me an opportunity to not only grow myself, uh, but also share some of the learnings that I've had, share experiences, and be able to bring a unique perspective about what we're doing with our clients to the listeners on the podcast.
Great.
Well, we're really excited to have you.
Really looking forward to what you do.
And the listeners won't have to wait long because that's it for me.
And on to Ricky's first episode.
Welcome to the ThoughtWorks Technology Podcast.
I'm the host for today, Ricky Zachary.
I'm here with Barani and Shodan.
Um, I'll let them introduce themselves.
Barani.
Hey, thanks, Ricky.
Bernie Subrimanium, CTO of India and Middle East.
Uh, been with ThoughtForks for 16 years now.
Happy to be here.
Uh, thanks as well, Ricky.
This is Shodan.
Uh, I lead our uh modernization services, and I've been in Thoughtworks for a little bit more than Barney, so beat him by two years.
Oh, awesome.
So uh we were today talking about our recently launched AIWorks platform.
We're working with clients all of the time.
What would you say was kind of one of the biggest signals that said we should probably do be doing a lot more investment in AI and uh taking a more platform-based approach?
Ronnie, what have you been seeing?
Yeah, I think I can trace it back to one of our clients in India where like significant number of thought workers, 30, 40 people, we've been building things for this client and we were having some early success, but we would like the entire work would get piled up in one line, like Pike it's not tested or it's tested, but we can't put it to production because it's stuck for let's say port to be open and and things like that.
So the first spark of we need a platform to do this better came from this fact that we can build things faster with AI, but there is still a number of things to be solved in the path for production.
That's why the whole platform thinking approach came is that we need a platform to solve all these problems or address all these problems in a systemic way.
That was the first spark, at least for me.
Shortan, what have you been saying?
Yeah, I think uh Thoughtworks customers have always asked us how to repeat the sort of outcomes that we have achieved outside of ThoughtWorks, right?
And I think I think we've always talked about our approaches and frameworks and written about them.
We've written lots of books about it.
Uh what was not there was codifying our approach into a platform to sort of achieve better repeatability, right?
So I think uh customers have always asked us that question, and I think for me that tippy point was when we saw some promise in a technology that could help us codify that uh the special source of ThoughtWorks into a platform to achieve that same outcomes and repeatable outcomes.
It's interesting.
Yeah, I I also see a lot of customers wanting repeatable outcomes at enterprise-wise scale.
So we're we're all on the team actively building the AI Works platform.
We all have different components that we're we're working on, and we're building them on the platform.
Varani, I know you're working on uh a piece of the platform.
Explain kind of what the AI works platform is from your positioning and and uh give a broader detail about what the AI works platform is.
Sure.
Yeah, I'm I'm gonna take a step back if that's okay.
Right.
So one other pattern that I observed and and others also observed is that there are a lot of things that we do in production, for example, for the sake of security and performance and monitoring.
Like because building with AI has introduced a bunch of tools, we need to start monitoring for cost in development.
We need to start monitoring for like leak of data during things are being built, not just when they are in production.
So that was another shift for me.
So the reason why I started with that is the part of like significant part of the work I do with the with the team is building that layer that gives you a common gateway for tokens, right?
Like so we API gateway or AI gateway in this case.
So that there is one place where we can say, as an outermost layer, can we ensure safety so that everything on top of the platform gets that as the lowest?
I say that as the lowest common denominator because security is like layers of onion.
You should have many, many layers as possible.
But this is the layer that actually protects the weakest link on the ecosystem.
So I would say the big part of the platform is how we handle security via guardrails and give visibility of what's happening in the system through a central observability, right?
So those are the two big parts.
And there's also a third element of the platform, which is actually governance.
Using this model has done this, right?
Um and and we need that for for the lineage as well.
So the third part of the platform that I work on is how do you govern uh this whole thing, be it cost um via by like limits of spend or be it observability or data where you can query what this team did on this day uh that resulted in this software, right?
Like it it's not to say that it has to be intrusive.
Uh the whole aim is to give these choices to people to build software in a way that's more safer and traceable.
Shodan, I know you're focused on the legacy modernization portion.
So where does your components kind of fit in in the into the AI works platform?
And kind of what do you think about the larger platform and how how how the components you're working on it fit in?
Yeah, so like I guess for me, AI works is more for uh like for a client, it's engineering that makes AI works, right?
I I guess we we had this sort of insight early on, and it's still true that just by itself generative AI is not the answer.
There's takes sound engineering around generative AI, like the control plane that Bernie was talking about.
But for every company takes sound engineering to make it less hallucinative, uh to make it more reliable, to make it more faithful, right?
So for for me, the reason we as ThoughtWorks are building this platform is to put that engineering rigor around AI to make to have the best of both worlds, right?
Like we want the rigor or that we've learned from the last 20, 30 years, but we also want the benefits of AI.
So for me, that's what I think about uh AI works.
Um, and yeah, as you said, I guess uh we I as part of my job I focus a lot on uh legacy modernization.
And I guess we started with a uh simple thesis initially, which I'm sure a lot of you will relate to, that uh with legacy systems, whether you want to modernize them or even keep the lights on or replace them with uh COTS product, I think what you need is insight into what that system is doing, right?
So if you don't have the knowledge about what that system is doing, any of these paths are going to be difficult for you, right?
But modernization is probably going to be the most difficult path.
But even keeping the lights on is going to be cumulatively and consistently expensive, right?
And this is a hard problem to solve because again, another characteristic or another set of characteristics of legacy systems is uh that documentation is generally stale.
Um, and the SMEs who knew it are either absent or uh no longer there, or they're very few and they form central points of failure, and generally there's no sort of automated test with something that as modern engineers we rely a lot on, right?
So uh so again, so with that sort of thesis of like we need to solve the problem of insight into your system as the first thing, irrespective of the path you want to take.
And so that's the sort of component that we started building out.
Um, and that's now part of the AI works platform.
Awesome.
And I know that there's other components that are that are there as well.
So as a follow-up, you know, we we talk a lot internally about this idea of code to spec and then spec to code.
How do you think, Varani, the platform is enabling kind of like that workflow to be operationalized at scale, both with the safeguards that you mentioned, but maybe also I think that um one model is better for doing enabling one of those workflows versus another model?
Like, how does some of that interconnectivity work with within the platform that you that we've been seeing?
Yeah.
So so this is this is interesting, right?
Like because in theory, uh, you can jump from I have this old system on my left side, I have a reverse engineer, and then on the right side is my to be system.
But in practice, it's it's really hard to do that, right?
Like, because you can't just go from A to B or you can't go from A to C without going through B.
Um, so the the most important part that the platform plays in this uh bridging the gap is what we call uh context library.
Um so in in in some sense, I keep saying that, you know, uh a lot of people ask me this question how is AI Works different from any other platform that is out there, right?
Um in in terms of technology, I feel it's very difficult to have a differentiation because in a way AI is leveling the field, not just for us, but for everyone.
Uh but what I feel is very unique is is this history that uh Shodan was talking about, and and we call it the hive mind internally, right?
Like, how have like the teams across the world and ThoughtForks have solved these problems, uh, similar problems in the past, um, which could I would say enrich the information that we are seeing for this particular client, right?
Like, so rather than just be the plumbing to connect the reverse and forward engineering, I think the role platform uh plays is how can we channel this collective knowledge that we have built over time as a relevant context, um, right?
And and this is easier said than that, right?
Like the mechanics of how to give the context, I think is a solved problem.
Uh, what is not solved is how do you create it, right?
Like uh we have this 20 years of history in the company.
Um, it's not that every problem that we have solved is relevant for the current problem.
Um, so so we have that, I would say two challenges, right?
Like, how do you curate and and keep it relevant?
And how do you know it's relevant for this problem, right?
I think we I would say we play when I say we, the platform runtime platform of AI works, um, plays a significant part in giving those capabilities so that the forward engineering can orchestrate which piece to which is relevant, which is not relevant, uh, and then they can go ahead from there, right?
I think that is the most critical part.
Agreed.
Yep, I I I agree with that.
Uh, mainly because in working with you know both of you all, what I'm saying is that that's necessary to make sure that we have interconnectedness between the flow, right?
Yeah, if we talk about the I know that there's been a lot of debate in the industry about what is the actual system of record for that flow.
Is it the spec?
Is it the code?
We're not here to parse that out.
But I I think that by providing that context at the relevant points within the flow, I think it's important because then you can have interconnectedness and you can treat the spec and the code as first class citizens there.
So uh Shodan, you know, we we both share a similar background and in doing some some legacy modernizations um there.
What do you think for supporting some of the legacy modernizations?
You you talked about discoverability.
What do you think are some of the key tools within the AI works platform that helps accelerate that discoverability?
Because I know I've been on COBOL program, modernization programs in the past, and it's very difficult.
We normally bring in a ton of people that have deep expertise in COBOL.
What what do you think some of the tools that are helping us to kind of accelerate that understanding for people that may just know Java or may know another language don't have deep expertise in COBOL?
Yeah.
So I guess um from a solution perspective, again, uh starting thesis was uh great.
You don't have SMEs, you don't have documentation, you don't have tests, but you have a gold mine in terms of structured data as code, right?
Like we've always believed in this adage, code is data, right?
So, and uh I say it's a gold mine because A, it's structured, and B, it is the most accurate reflection of what's happening in your organization, right?
Documentation can be wrong, diagrams can be wrong, but the code accurately reflects because that's what's happening in production.
So we start from there, right?
Like if the code is and is your most accurate representation of what's happening, how can we use generative AI to use that structured data as the source of truth, but be able to project that data in ways that are help both humans and machines move forward in their modernization journey, right?
And I guess that's uh the the for me the combination of human and machine is important there because at least right now we believe this is a platform-enabling services uh solution, right?
It's not a solution where you have a product, you click a button and boom, you get you get a modernized uh uh output at the end of it, right?
Um, so we've focused a lot on how to use that code and project it in various forms so that humans can start understanding what's going on in their system, and as as as we've been talking about, produce specifications that machines can use to uh forward generate a newer form of that same uh behavior, right?
And I guess in our sort of journey in building specifications uh for humans, we've realized that we need to sort of build it in different formats, right?
Humans love um to start with high levels of abstraction and then keep zooming in into areas of interest, right?
If we only took a strictly textual specification uh approach to this, uh any 10,000 lines of uh code would be about 10,000 lines of specification of English language, right?
It's not a it's not a human scale problem anymore.
So we need to provide summaries and abstractions so that humans can understand it, and for them to be able to interrogate um those answers in more and more detail where the wherever wherever they wanted.
So I guess that's sort of uh is the main uh goal of the component that we were talking about in terms of discoverability, um, which is being able to provide specifications in different formats for both humans and machines.
I'm gonna follow up on that because I'm working on uh a product modernization with the with the client right now.
And the the ultimate conclusion of that, that you know, which we start with a specification, we start with the code, it's the data, but a lot of times um when we're modernizing, we we're not we want to also optimize both product user journeys, uh the capabilities that are there.
What are some of the what are some of the techniques that we're using from a kind of capabilities standpoint to help to understand what the scope of the system is um and and those types of things, so that we can more accurately for forward engineer a new product that's gonna meet client needs.
Yeah.
So I guess we've uh I mean, two other sort of techniques to throw in that we've always been fans of is A incremental modernization, right?
So it's not a one-off and B uh that or the unit value of modernization is greater when you bring some change in it right and so those changes as you can as as you described could be things like I want to change the behavior in my 2B system or I want to compact some things that are not useful to me anymore right like those um those changes could be of different forms but the unit value of modernization increases the more changes you make we allow for humans to or we assist humans to make these changes via two forms of specifications uh one form of specification that we build out is a capability map so that allows you to give give you that gives you sort of a town plan view of a large system uh one way uh we've seen uh designers use that that specification is to take buildballs by decisions right so so but but but by giving uh uh the humans this sort of projection of large systems where they can sort of take different decisions for different cable tees is something that they've not had in pre previously that exercise would have been a couple of weeks or even more uh locked in a room with a bunch of SMEs doing that, right?
So that's that's sort of one example to do it.
The other, I mean, the other way that specification could also be used is to figure out your increments, right?
As I talked about, like large systems are not currently uh you cannot replicate that behavior in uh in in a second or whatever is the right sort of uh time duration to use.
So you have to do it incrementally, but that needs the problem of what is an increment to be solved.
Again, when humans have have this sort of experience to do this and sort of can do it, but again, we're trying to use technology to sort.
The other type of specification that we've started building more recently, right now, is to borrow from uh the event storming techniques, right?
Which which again we were we would love to sort of go into the room and draw out like uh for large systems because that'll quickly give you an idea of the sort of business process that's happening, right?
So X command acted on Y aggregate and resulted in A event and that that triggered more things, right?
So again, using our base knowledge graph that sort of you build out, we project an event storm map uh of the system.
And again, you could sort of use it in a few different ways.
A, it it goes back to that primary sort of hypothesis, it gives you more knowledge about what your system is doing in a human understandable way, and B, as the designer of the 2B systems, it gives you a canvas to make decisions around your 2B system, right?
Dora.
No, no, I was gonna add, I think there's a lot of confusion when we say a spec.
What is the spec?
Right?
I was gonna ask Shoddin, right?
In your mind, the last two things that you said, to me, they are like projections or dimensions to understand what is already there.
And like I would personally not call that spec.
Yeah.
So I guess I guess so I think I think it's about how loose and tight you want to be with the words.
So I agree.
Like uh at one level you could say they are specifying the system at a level of abstraction for humans to understand.
And another level you could say there's because they're they're they're not specifications have a mathematical connotation, like because they're not exact, they're not specifications.
But you're right, like my natural instinct is to not call them uh specification.
The reason why I think it's important to give that distinction is um a lot of people think a spec is similar to what was there when they were doing waterfall.
Yes.
And and this is not that, right?
And in in maybe we need to invent a new term.
Uh another another confusion, uh maybe it's worth spending one more minute on this, is what I find most confusing with spec is we write what needs to be done uh as in the functionality, and also how it has to be implemented in the same document.
And and and to me it is confusing because they are two different things, not just in like now, but they are also two different things that happen at two different times.
Yes.
Right?
And and one, like I want this piece of functionality.
Maybe that is also evolving, but could be slowly evolving as opposed to how that has to be implemented.
We might have to iterate that five times uh faster than what is required.
Um so that's why I feel Vietnam ill-equipped to call everything a spec.
Um we need a new turn uh maybe we need something more structured uh that's another problem that I have with spec is like what is the structure there there isn't right GitHub has one Amazon has one there's a bunch of these companies generating these there's not a standard specification for it and that there's not a standard specification for the specification Bernie you mentioned something earlier in the conversation that I I want to to revisit um when we were talking about kind of like this idea of platform governance so you know I I I do a lot of platform engineering that's that's the majority of the the the work that I do with plot uh business and and and engineering platforms one of the things that has come up time and time again as organizations shift from these kind of individual tool decisions so kind of what that journey looks like is hey we're an enterprise and we went out and bought a bunch of GitHub co-pilot licenses rightly so and then I want to turn the corner from that and make my AI investment worth it at enterprise-wise scale while still balancing kind of the governance and the controls and a lot of a lot of those things.
How have you seen kind of the idea of the platform, AI works platform, evolve from kind of point to point-to-point solutions being implemented by enterprises to now us trying to provide clients with enterprise-wide business value while still maintaining the security posture there?
Yeah, I think this is very interesting and and we bump into this every time, right?
Like we we can have our own opinions, but when we go into a client ecosystems, like you said, hey, I don't have light LLM, I have a Kong AI gateway, right?
I don't have uh co-pilot or I have Claude, or I don't have Claude, I have Copilot.
I think these things come up all the time.
Um and and that's why w when we thought of the architecture, it's more of these are the components that is required, but you can swap out anything and everything.
For example, let's say um they have a strong guardrails already set up in the enterprise, we can hook into that.
If they are an AW shop and they're already using bedrock, we can use the bedrock all right.
I think we are very flexible from that aspect, like we're not tied to a provider or an implementation.
But the fact that we need to have a central place where we can control for governance is is the mandatory thing, right?
Uh other parts are very fluid, and we are also discovering like a bank would need a much stricter guardrails than say a lead rate retailer, for example, right?
Um and moreover, different parts of the platform.
Let's say if you're building something very sensitive, for example, you're dealing with pins and debit card pins, uh, maybe you have to be compliant for PC IDS, even at build time.
So that's that's that's a different thing.
So we need to provision and segment part of the platform uh for a certain subset of use cases.
So we've seen a flavors of this, and it'll always be uh very reactive, uh, but we have talked through to some extent to have flexibility in the implementation.
Another follow-up about what what's in the with within the control company within the platform.
A lot of our clients are constantly struggling right now with the actual proving the value of AI of their AI investment.
Um how are we instrumenting kind of the data around the SDLC to help them prove the value of not only the AI investment, but just using the AI works platform?
We have to ask this question.
Um yeah, this is a great question.
I think let's be honest, right?
Like we, when I say we, the whole industry uh is struggling and will struggle uh to articulate productivity and measuring and metrics uh because they are inherently hard things to solve.
Not that we don't want to solve it.
Um D uh response from from my perspective for this is that whatever tool sets that you're currently using without AI or with AI, I think keep continuing to do that because otherwise, if your baseline is different, uh we would be happy with the productivity gain, but that won't be reflecting in reality, right?
Like so if you're using Dora metrics before using AI tools, continue using it after.
So there is a common frame of reference.
Or if you're using something like a flow metrics, continue to do that.
So from the AI works platform perspective, we are flexible, and this is the part that we are still actively building.
Like one option is we will integrate with Apache DevTools, right?
That way we can tap into the ecosystem of tooling that's already being integrated, right?
Like we don't want to reinvent everything for every client.
So that is one approach.
But yeah, this is something we want to test and learn as we go ahead.
Agreed, agreed.
I asked that because I know that we're we're we're thinking about that quite quite a bit.
Um I wanted to also follow up with uh a technical question.
Um you mentioned this word ingestion of the code.
The code is the data, and we're ingesting the code.
Why why are we ingesting the code?
What what kind of value do you think that that provides?
Because I have a lot of clients that come to me and say, I could just give the code to you know a cloud, uh, you know, Opus 4 or 4.5 or Gemini 3, and it'll summarize the code.
What what do you think is the value add of that ingestion portion that that we're doing, and why you think it's so valuable?
Yeah, and I would say I think uh there are probably two answers in there.
One is scale.
Uh I think most of these tools can probably do a pretty good job at um 10,000 lines of code or that sort of uh scale about.
Uh but like we we work with a lot of large legacy systems, and uh large could mean hundreds and thousands, could mean millions, could mean tens of millions, and at that scale, uh these tools just don't work, uh partly because of their context window limits.
Um, and as uh other people have mentioned before, right?
It's not just a context um window limit problem.
Uh one of the well-known tricks of working with LLMs is to give it the right context.
Um, and the example I always use is it's like an open book exam.
Uh if you know where the answer is, great, you found it.
If you don't know where the answer is, the book doesn't help, right?
So if you if you just give LLMs a lot of context, they're going to struggle and actually hallucinate even more than you would expect it, right?
So we've built this solution to be able to scale uh to large uh code bases.
And then I guess also like the other projections we talked about, right?
Like the event storming map um and the cable D map, right?
These are things that are built on layers of the base ingestion that we've done, right?
So and we've sort of done some benchmarks with these other tools that are out there right there, and the amount of uh detail and um I guess faithfulness with which they can represent that information is much more lacking.
So I would I I would say primarily scale, but secondly, like like you need you need more than be things like explain me this code, which I agree is a solved problem, and you probably don't need things like our uh platform to help you uh explain the code.
But when you start going beyond that in terms of uh especially in the areas I work, right?
Help me find an increment, help me figure out how do I change the business process of this whilst I want to modernize.
I think that's where you need uh as I was saying, engineered solutions that can marry the benefits of generative AI and the benefits of all the hard learned lessons that we've had from the last 20 years.
Yep.
That that's that's a great answer.
I'm gonna use that with with in my next c conversation.
Um with me?
No.
So Bernie, one one more follow-up question, uh about the the the metrics.
Um not not not as hard as this the last one.
Uh so one of the things that I think I'm personally kind of fatigued on is this idea of the productivity metrics.
Um we've been talking about productivity metrics for the greater part of four or five years and AI has only accelerated that.
But from a kind of platform within the AI works platform, I know we talk a lot about interconnectedness of the workflows.
I think I liken them to kind of the idea of AI powered and enabled golden paths.
Do you think that the platform enables kind of shifting some of the feedback loops to the left a bit more for some of the developers?
And what are some of the techniques that you're you you're seeing us explore and build into the platforms to to solve that problem?
I I asked that because I think that that is an answer to kind of the productivity question, which is well, we're gonna get AI operationalized at scale into the hands of developers sooner.
And we'll worry about the the larger productivity metrics, the hours saved as a byproduct of that and be able to reduce toil and cognitive load.
So that question about what are some of those techniques to help shift left, w what do you think we're thinking about in the platform around that?
Yeah.
I think this is good.
I'll add to what Shodhan said earlier, right?
Like AI is good, generated is great, um, but it's only gonna be as good as the input that you give it to it, right?
Like so one of the rules of the platform is what other richer forms of input we can feed into the developers so that at that time um that they build the software, it is kind of well informed, right?
What w one like a concrete example could be that I am building this critical part of the journey of the product, right?
This is not an auxiliary feature.
I have to be very careful.
Uh, like this change, what is the impact on the performance is gonna be, right?
So when I'm touching that part of the system, what's the current P99 latency that I have access to?
Like without a platform, you have to juggle around three or four systems to get that, right?
Like one of the goals of the platform is how can we give that context to the developer, right?
It is not going to be easy because what we are talking is we need to take telemetry from production and give it to a developer when they want it.
Uh, right, there is a lot of security postures to be corrected.
But if you are only using AI to do the same thing that we used to do, just better, faster, that's not gonna be enough, right?
We should be enabled to do things that are different, which was otherwise not possible.
AI could be an enabler or a platform could be an enabler, right?
So that's the rule uh of AIWorks is that how can we enrich not just the stories and features and context of the solution, but the other things that are happening in the production ecosystem back to the development.
Go ahead, Sean.
I I I I I guess I want to add something to this as well, right?
Like, I think there's over obsession with how much gain in product.
Oh, can do I can you uh achieve a 60% production productivity gain or 70% product rate?
Whereas in reality, the focus just needs to be on improvement, right?
Because like this is like the my financial education started pretty late, so I learned this pretty late, right?
Like compound interest is cumulative, right?
So when you start making improvements, they c accumulate over time, right?
And so that's more important than obsessing about a target of improvement that you want to hit, right?
That target will come.
But the but more important thing, and that's where the whole feedback loop and all those practices reinforces that as long as you constantly consistently, continuously keep improving, you'll sort of get to uh the best place that's possible.
Yeah, I think that's a great response.
I I I I I really like that.
Um You're not gonna use it?
No, not that one.
I think the other part of that uh conversation which triggered in my head is is that a lot of the AI tools and the the the platforms that are external to ThoughtWorks are really focusing in on the developer.
Uh however there's an opportunity for the use of AI to I I think one of the terms is democratize the you know in engineering.
How how do you see the work that we're doing on the Airworks platform kind of even shift further left and make the SDLC more of a PDLC?
Uh I was having a conversation about UML.
That was a language that we used to talk to each other as developers.
Do you think now that you know we were talking about words?
Do you think now there's the need for a new concept or new word that talks about this language that we're gonna use to talk within the platform between product, uh the m managers and owners, developers, SREs, or will the spec, as we we we've been saying kind of loosely, is that going to answer that question within the platform?
I I think this is the deepest question so far.
Um I I say that because yeah, the spec is going to be the vehicle that carries that information across the stages of SDLC.
But um we almost took our workflow for granted for a long time.
Uh I think that workflow is changing uh because good or bad, the granularity of work is changing, right?
Um I think we had agile and we still have agile, and and it is meant to have a quick feedback loop with certain constraints in mind, because we couldn't iterate at and build things at capability level before, but you could do now, right?
So the I mean the the best part of agile is it keeps evolving, right?
Like so the question is what is this agile agentic workflow that we should have it on the platform or encourage people to follow that path on the platform?
Uh it could be as simple as we used to promote pairing within the same discipline before, like a dev and a dev pairing.
Uh I think we should promote a lot more of a product owner and a dev pairing and a dev and a QA pairing, right?
Uh or even a QA and a product owner pairing.
Like all these interdisciplinary pairing is is almost a mandatory thing right now because uh a spec won't be complete uh if it is not complete from all the dimension, right?
Um in some sense, we are shrinking the time, uh, which is putting a lot of constraint on what a spec is.
Uh but the shrinking in one dimension we are shrinking the time, in another dimension we are increasing the unit of work.
So we can't pretend that way we build is not gonna change.
Um do we have all the answers on AI works?
I'm sure we don't.
Uh, but we are experimenting this this interdisciplinary planning.
We've seen it work uh very well in uh in a few instances uh with or without the platform, right?
Like so we want to definitely codify that in in as much as we can in the platform, um, so that you know, use the word right, like it's a paved path.
Right?
Like so it's a paid path so that you know it's easy if you follow this path.
It doesn't mean you should this is the only way to do it.
Um that's how I see it, yeah.
I'm gonna ask one final question just to kind of close us out.
Uh we again we're all working on the platform.
What is kind of one feature that in in our in in you all's respective areas that you think, hey, that's going to be something that I'm really looking forward to, really exciting to experiment with and bring to our clients.
For me, how we can use the new ways of working, but still not forget software is still a social activity.
Uh we still need to build evolutionary things.
You I mean, you can't go from zero to 100, uh, right?
Like, so it is going to be small incremental evolution, but that what was small unit of work could be a large unit of work, but it has to be iterative and and evolutionary.
I think that's one thing I'm excited about.
It is very hard to do that uh in the platform, but it is also the challenge that I'm I'm ready to take on.
Sholin?
Uh yeah, good question.
I guess um, again, like sort of focusing into my area of work modernization.
Uh, there's this translation required from what your as is system is to your 2B system.
And so far, most of our work has been focused on how do we unravel the business logic of your as a system.
And so now we started focusing on a different persona, the designer of your 2B system, right?
So, what what tools, what vehicles do we give them so that when they see more of the Azure system, they can take meaningful intentional decisions that help them change and build a better uh 2B system that's more fit for purpose for them to help.
So I think we've just started on that journey, and I think this is an important persona uh to address.
Like modernization is almost incomplete without us.
So yeah, that's the thing I'm most excited about.
Great.
Thank you all for joining the ThoughtWorks Technology Podcast.
Um, appreciate having you all join me.
And if you want to learn more about AI works, uh you can go to the Thoughtworks.com website.
We have a landing page there where we have video demos and we've got a ton of different content to explore.