# Enterprise AI Strategy: Platform Engineering and Governance

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

## Transcript

Hello everybody.
Welcome to another episode of the ThoughtWorks Technology Podcast.
Today we're looking at our looking glass report that we published a couple months ago and the effects on the real world and our clients and uh the folks at ThoughtWorks.
So we're lucky to have a couple guests with us today that you've heard from in the past.
In fact, one of them is a is one of our new hosts, but they also have exactly the experience we're looking for.
Um first off, uh if you wouldn't mind introducing yourself is Thomas Squale.
Uh perfect.
Thank you.
Uh Ken.
Uh Thomas Quay, I'm the chief technology officer for the Americas here at ThoughtWorks.
Uh I get to work very closely with Ricky and the rest of the team on our own agentic journey.
We've not only been working kind of in the AI space the entire time I've been at the company, but also uh it's been uh nice to see kind of the the I think February 2026 was a pretty uh significant inflection month for uh everything we've seen so far.
So Ricky?
As Ken mentioned, I'm one of the new hosts on the ThoughtWorks Technology Podcast.
But my day job is I'm working with Thomas on uh leading our both internal developer platform and platform engineering practices, as well as our external client engagements from a platform engineering perspective.
So I'm focusing a lot on the most effective ways that we build platforms for both ourselves and our clients.
Um I'm working with our AI works team on how do we build our developer platform and then just scaling the use of AI across uh our client enterprises and our client client customers.
So it's it's it's very pertinent to look at the looking glass and see that there's a lot of platform engineering focus and platform focus there.
I invited the two of you specifically um because you both bring a little bit different direction that you look at this from.
You know, Thomas, you talk to enterprise leaders at the CTO level and stuff every day from the executive mindset.
Uh you know Ricky, most of your background is in actual hands-on enterprise modernation platform, et cetera.
And so you know I really thought it would be be good to get both feedback or both uh impressions, if you will.
Um so Thomas, as I mentioned, you talk to enterprise tech leaders every day.
You know, uh we hear about gaps between their ambition and what they're actually seeing.
You know, what does that look like when you're when you're talking to a CTO or a CIO, you know, what are the gaps that they're worried about?
What are you seeing on the ground?
Uh the biggest gap that I see between you know for most folks is around uh AI fluency, being able to have their teams be able to uh interact, engage, work with these tools, be able to understand kind of where the where the perimeter really sits, where guardrails, evaluation frameworks, uh data labeling, things like that need to happen in order to be able to bring things forward into production.
So it's not just uh, you know, if you think about kind of the the the in the context of software engineering, the inner loop being the creation of the software and the and the outer loop being kind of the running, the CI CD observability and so on and so forth, uh, you know, uh dimensions, we're starting to see this kind of uh orchestrator role kind of become emergent, and that is very much key in what takes to be able to take a you know a a C-suite's ambition for being able to be an AI enterprise and and being able to bring that to a production uh state.
So I think that those are the one of the one of the areas that I hear the most.
So you've also Thomas been quoted as saying that organizations to need to be brilliant at the basics.
What does that mean?
Well, I always come back to kind of the core mechanics around software engineering principles, especially when it comes to organizations that are greater than 50 people really taking a platform approach to what they're doing, whether that be CI CD, DevSecOps, software bill materials, or policy as code, those things as kind of good first principle practices at the enterprise scale are critical for being able to have success in an AI-driven landscape.
Because what ends up happening is that the pace of change and the pace of of uh you know, kind of ambiguity being able to thrive inside your operational environment, uh, by being brilliant at the basics, you have the ability to now control for the things that are controllable, uh, and then be able to work with a non-deterministic system in a production environment.
So that's really what I kind of come back to.
Real one of the reasons why Ricky and I work close so closely together is because the we view the kind of the platform, the ambition of many of our customers is being enabled by platform.
Yeah, which is a great, great segue.
So, Ricky, you've spent years helping people build internal platforms.
Um, so, you know, what does this change about what a platform is need to be?
I don't think it changes the core engineering foundations of the platform, right?
We still want to have uh platform abstractions.
I think we still want to have uh basic platform engineering components around uh infrastructure as code or around CI CD pipelines.
I don't think it changes some of those core foundational elements.
I think what it does change is the interaction modes that the developers now can consume those platform capabilities using.
Um it's this idea that before it was going to be the IDE or CLI or the terminal, and now what AI is adding is these are different, these additional interaction modes, the different operating modes that the platform now can expose capabilities to.
So now you can do an NCP, you could do an AI agent, you can do all of these new modalities that are there.
Um so that's what I think it does change.
It changes the interface that the developers are going to be utilizing uh to consume platform capabilities.
I think I think that that's the interaction model that it changes.
And so then, you know, Thomas mentioned a second ago that February of 2026 was a was a big month for AI.
And frankly, some stuff like back in December, different models coming out with Opus and and so forth.
Um, if the bottleneck isn't the models anymore, I mean, if they're if they can write decent code and and we have, we know what we have to do in a platform, doesn't mean we've done it, but we know what we have to do.
Um, question to either or both.
You know, what is the bottleneck?
How do these folks get AI from experiments to production?
From my view, it's basically as follows.
If you over-rotate and you over optimize one aspect of the value stream, uh then the other aspects of the value stream start to slow you down.
So we now see this notion of uh, you know, um other areas around being able to absorb the change.
So if you have these agents that are moving at kind of speed and scale, now we have the opportunity to be able to kind of upskill the rest of the organization as it relates to uh kind of next steps.
So when I say next steps, I'm talking about like, you know, what is it me to be product led?
What's the evol evolution of the product manager's role, was the evolution of an operator's role as a kind of uh maintaining production systems and so on.
I agree with those those statements.
I think one additional thing that I'm seeing as as as I'm building more and more of these platforms with clients is that the bottleneck is no longer kind of like we're reaching the tipping point where it's not the models and those things.
I I think from a platform perspective, one of the bottlenecks is we're not seeing the um the actual platform product thinking that we would expect to see within the platform.
I think it's there's a parallel to when the when when we started to do agile as a process, that there was this idea that agile was doing a lot of exposing some of the organizational issues that were in an organization if you tried to go and do agile without having some of the organizational issues fixed.
Um that that happened repeatedly as I was kind of growing up in the consulting world from an agile perspective.
I think we're now seeing that happen in the platform space as well, where the platform space is not just here's a tool to do infrastructure as code, here's Terraform, or here's uh you know GitLab or or or Soccer CI to do these things.
It's the actual product thinking to interconnect those experiences.
And what the addition of the LLMs is adding is hey, now I can write way more code.
Now I can, you know, produce way more code as an output, but none of those other parts of the platform are interconnected enough to be able to get that code into production in a consistent and seamless manner.
So I think as people start making investments in platforms, they still see it as just a collection of tools, not really applying that platform product thinking.
I know that that's similar to what Thomas said, but that's a kind of a tactical example of what I'm seeing as well.
So in in looking glass report, we talked a lot about you know what does it mean to rebuild platforms and ecosystems and all of that.
Um, you know, there was a whole lens around AI for software delivery, AI first software delivery for developer experience.
Sorry, I'm used to saying DevX these days.
Uh AI ops, federated data platforms, et cetera.
You know, uh, so Ricky, you know, you've talked a lot about developer experience as a key trend, uh, golden path, if you will.
How does this evolution set the stage for AI first delivery?
I think repeatedly I've been talking to clients about um making the easy way the right way, right, for developers.
Um, and that's kind of like the key unlock for focusing on developer experience.
It's the idea that if I create the golden paths, if I have uh, if I have the right developer experience, if I'm focusing in on that, even if we're talking about producing code with AI or we're doing agentic workflows or those things, if I make the easy way the right way, I'm gonna have great adoption of the of the developer platform.
I'm gonna have better outcomes in my business platforms, in my data platforms, all of all of those elements that are there.
I think that that's the that focus on developer experience, operationalizing that through golden paths, with the outcome being making the easy way, the the right way the easy way.
I think that those are some of the outcomes that we're looking at.
It's easier said than done because there's a lot of operational pressure, organizational change.
There's an operating model component to it.
There's a change management and adoption uh model component to it.
But that's what you want to do to get that outcome is focus on those things.
It's a less of a tech problem.
I know uh some of the folks from Google say, you know, it's a platform engineering is a socio technology problem.
It's more socio than it is technology.
So getting those uh things and those elements associated with the socio problem part of the problem is very important.
The technology is fairly easy right now.
It's it's interesting that you brought that up because you know, Thomas, you were um in a you were interviewed by I think it was Information Week recently, um, and made the made the comment or the observation that AI readiness is a business aligned transformation, not a technical project.
So what does that mean from if you think about the culture and organizational aspects?
What does that mean?
The models are starting to become commensurate with each other.
Yeah, obviously Claude's got its strengths, OpenAI's got its strengths, Gemini's got its strengths, but what we're seeing is that it's the context that kind of uh lives above them that is really the the problem, the the opportunity, I should say.
When I think about enterprises and they're kind of dealing with uh, you know, kind of AI as a as a kind of part of their operating model, it needs to be understood.
Like the the I you know, I come back to AI fluency.
If your executive team is understanding how AI is going to be applied in their their functional domains, they're going to have a greater uh uh desire to see it be able to be incorporated.
Our CMO is one of those people that you know really kind of took AI as a part of how do they accelerate the operating model for that part of the business.
And then that was one of those things that I saw as kind of like, okay, that's an example of how you see these things go downrange.
If the COO for an organization is is really uh looking at their business process and then the uh the art of the possible there, that's another aspect of how it could actually be incorporated in.
But the thing is is that the technology organization that actually would be building, delivering, managing, and scaling that, that's not the the hardest part of that problem.
It's actually getting the adoption in these in these functional areas of the organization.
So if I think about kind of like uh one of the constructs that I I worked on for a long time was this notion of in the inner loop, you would have this notion of how software was developed, this this middle tier where you would start to see kind of operational business processes being affected in the outer tier, you'd start to start start to see things that were facing stakeholders and customers and so on and so forth.
That that that outermost tier, the onion is the most risky because that's the area that you have the less, the least amount of control for.
But when you have an operational executive or somebody that's responsible and accountable for their outcomes, they're going to be driving it and being able to understand it.
So this also is kind of brings up another issue, which is now this notion of um like shadow IT, where people are starting to, you know, or shadow AI and shadow IT, where you're starting to get, you know, uh systems that are being put into uh mission critical environments or or where in fact they uh might not have been vetted from a security dimension or you know, kind of a risk dimension as well.
I think that largely many of these things are risk discussions.
So if you think about the opportunity to do things like legacy modernization or any of those things, you start to approach that from risk as opposed to technical feasibility.
We talk a lot about platforms.
You know, the other angle about this, of course, is the data, right?
So I mean, we can change the the code on top, but the data's really where usually where a lot of the value is.
Um, you know, what how does that need to evolve?
You know, we I mean, we had data lakes for those of us with gray hair, um, moving along to product centric, you know, what how does the data platform evolve with this, either either or both?
I I I think about it from the bottom of the infrastructure up.
I think in an AI world, I think that we are now going to be even more heterogeneous about the infrastructure that we need to deploy in the runtime to support the different agents.
So I think that now there's this mixed environment where I may on the Kubernetes side, I may be deploying a lot of GPU based clusters and I need to be able to maintain that uh and and utilize that for different ETL packages for different AI agents that are running.
Purely on the data side, now I'm moving from what we had where there were a lot of data lakes and there were a lot of data meshes that some of those endpoints are gonna now be knowledge graphs or graph rags or all of these very AI um enabling data uh endpoints that are there and and and data stores that are there.
So now I think that what we are seeing is the ability for the developer and business platforms to support these mixed and very heterogeneous data in data infrastructure pieces that are there.
Um, and then expose those f as either building blocks for AI agents or for business outcomes that are there.
So I think that we're seeing that infrastructure f that was usually dedicated for data, um, pure data applications converging with normal AI agent applications, engineering uh applications, particularly on the Kubernetes side.
And now platform engineering teams are converging and have to manage a lot more infrastructure.
So from a bottom to the top or bottom up standpoint, it makes it very, very interesting for new platform engineering teams that were normally only managing just compute infrastructure or basic storage infrastructure to now having to start to manage these more exotic um data uh data storage solutions to support the AI agents.
It's a it's around this notion of context.
I mean, if you think about like the the the swampy nature of data lakes that kind of occurred over time, you know, we're gonna have different levels of readiness for uh your what is gonna be powered by AI.
I think that that is a very uh not only important, but it's a critical aspect of whether or not you're gonna be able to bring a system forward.
One of the one of the uh greatest inhibitors that we've seen in going to production is data readiness.
So, you know, people are very comfortable with an upc environment, but then all of a sudden they realize that the the regulatory indemnity that goes along with putting the system in production is one that could actually introduce a lot of risk to the enterprise.
So those are things that are gonna be uh critical for uh enterprises to understand.
I think that it's also important and understand that it's unlikely that your entire data state is going to be at the same level of readiness.
So you kind of have a medallion architecture for your data readiness as well.
Uh, so I think that those are going to be portions of how you'd be able to approach that.
And that means like, you know, um, you know, again, it depends on what the blast radius of what the problems that you're gonna solve for it.
You know, context is king.
We've seen a lot of uh uh things happen for engineering teams and product development teams internally that far outstrip the capability of what you would be able to put in front of a customer uh in an in a regulated environment.
So, you know, the you know, we we've all heard the funny horror stories, uh, or they're only funny if they didn't happen to you.
Uh so that's that's really kind of what I when I think about kind of the data readiness problem.
So you've both talked about you know the ROI of all this.
Uh I was talking to a project lead the other day that on their project, they're spending half a million dollars a year just on LLM access on tokens and whatever.
Uh and then of course there's other costs.
Uh uh you Ricky, you've talked about the Dora and space metrics.
Thomas, you've talked about you know just the need to define and track a ROI.
How do people measure value?
How do they know this is working or not working?
I'm going to give an example of what not to do as an exam as a good example of what to do.
So I I've been talking to a lot of clients about this, and I advise them not to think about kind of like the traditional counting metrics.
So like hours spent right doing a particular task or um amount of lines of code that's produced by an LLM.
I think that those types of metrics are traps because it makes the conversation purely about productivity and not about the reduction of friction or the use of AI on maturing a particular practice.
So a very tactical example about that is a testing cycle.
So most organizations have a very manual testing cycle that's supported by you know a bunch of people going and clicking buttons on a UI to test or verify something.
I can read I can reduce that by a certain amount of time on each individual person's activities, or I can think about what is the actual toilet in the system that's there, right?
So the toil in the system may be while I've got to have manage a spreadsheet to manually test these things.
Great.
The entry point there would be okay, we want to extract that toil, we're gonna increase automation.
We're not necessarily tracking how long an activity took, but we're tracking an AI metric that's a part of that.
So I think that the in that particular example, the automation uplift would be the metric that I'm I'm I'm I'm tracking, right?
Number of tests automated, uh, number of tests using AI elements, those are more important elements of it because you can use those as leading indicators of is the AI experiment or my capability, is it actually providing value, right?
Versus we're going to introduce AI and see how many hours we save.
That could be because of other mechanisms.
It doesn't give you an accurate reflection.
So we we are moving towards like these non-productivity leading measures so that we can actually accurately measure the impact of AI as it's uh being applied to our clients.
I I still think that Dora and Space are valuable metrics as a part of that conversation.
I think that we're also doing a lot of research on what are going to be the next set of metrics for an AI enabled or an A AI native world.
And we're thinking about, you know, token cost, um, how does that actually play into the day-to-day lives of a developer, right?
So is there something around token cost and their effectiveness or you know, a bunch of different elements there.
So we're really exploring those those uh those elements.
I don't think that there's one right answer yet.
Um, you know, something that's similar to Dora in space for the new AI native world.
So we're taking this very deliberate layered approach when it comes to that and from a from a developer and engineering perspective.
Um just on the ROI side, I think it depends on what area you're looking at.
So if you think about there's no sort of Jevons paradox, you're gonna be filling in the uh the the use of that time.
If you look at engineering as a manufacturing-based process with you know certain lines of code per engineer, you're already looking at the wrong numbers.
And I think that to Ricky's point about Dora and space, I think those are critical elements of us to see that evolution.
So we see, you know, for example like the DX folks that are evolving their own metrics, they're putting out their own state AI report, very much looking at these kind of elements.
When you think about the ROI for a call center where you're introducing a call center agent, you have a completely different set of ROI metrics that are going to be uh satisfied.
Uh if you think about NPS scores and things like that, that's when you're facing a customer and and the ability to have kind of uh you know uh an avatar based agent interacting with a human based agent and seeing the controls and how you deal with those handoffs you could be looking at that and how you deal with like managed service L1, L2, L3.
You know, all of those elements have different ROI measures than engineering.
Engineering is going to very much be like you know uh you know kind of looking at everything from what's your stability scalability, what's your security dimensions, whether or not you're introducing risk, whether or not you're able to go fast and deliver features that are delighting your customers or your stakeholders.
And then are you doing that in an efficient fashion.
I think that what we're seeing from an ROI standpoint is when you look at token costs, that's a that's a new gravity well that hasn't existed before.
We view that AI ops is part of FinOps and that needs to be considered as a uh kind of a a first class consideration in that dimension.
But I would argue that a well-formed you know environment where you're actually building out your engineering teams to take advantage of this, the the advantage is far beyond just you know ROI and it can't just be a efficiency play.
You know, we've had conversations like, for example, uh some of the heads of tech and other CTOs and I have had conversation uh specifically around the only way that measure makes sense if you're looking at it from an engineering team, if you locked yourself in amber and are no longer evolving to where the market goes.
But as your competitors are also working against this space and taking advantage of these tools and techniques, they they they are going to be the thing that takes your ROI and eats it as your your their mar their ROI is your margin, you know, in that in that scenario.
And that's an example where we just see the operating environment, so for so many of our customers that you know have to deal with you know uh legacy companies with hundreds, uh hundred plus years of of kind of uh life in their business, uh competing with an emergent uh you know AI native startup that has come in and with unencumbered by all of these kind of infrastructure.
So one has a huge install base of a customer, uh installed base of customers, one has you know the ability and agility to be able to nimble and move nimbly inside a market.
Those are different considerations when you come to ROI.
Because if I was just gonna say, hey, is your token cost high?
Are you getting the uh value out of that?
I think we need to focus on the business outcome being driven from it rather than just a raw cost metric.
If you think about ThoughtWorks as an organization, when we look at what our token cost is, I would argue that that is a false measure uh uh for being able to kind of understand where the value actually comes from.
Uh again, you know, if your issue is token cost at this point, you're probably focused on the wrong activity.
You know, talking about the pace of change, two of the other lenses in looking glass.
The first one, uh lens two was about agentic workflows and embedded governance and that sort of stuff.
Uh, and then lens five was about responsible foundations.
We have human oversight, computational governance.
Since that was published in January, we now have open claw and lots of other things out there that have you know really made a splash.
You know, so so now that agentic, I mean, it's a it's a real thing for sure.
I mean, obviously, no one's gonna argue with that.
Um, you know, Thomas, you've talked about security implications, excuse me, of autonomous AI agents that traditional security architectures fail when systems are making their own decisions.
You know, what is governance look like these days?
Well, again, uh come back at the be brilliant at the basics as a kind of key notion of being able to absorb risk.
Understanding the risk that you're absorbing is is a key aspect of that.
Google's published new uh AI agent agentic uh security standards, MITRE, Atlas have uh done that as well.
MIT has done that.
So there is a kind of a growing body of understanding about where these dimensions are, but I don't think one framework is the only one that you're going to be able to do, whether the ISO or other emergent standards are going to be part of this, I think that what we need to do is be able to go and say, okay, with security by design has got to be a uh uh a component of that.
Uh previous article uh that I participated or wrote, I can't remember which one it was, but basically it was this notion of understanding when a guardrail strike happens so you could actually intervene and actually view that.
So it's not just an agent that's hitting the guardrail over and over again, and you don't have a governance process to be able to absorb or or inspect that change.
So I view that kind of notion of an agent as a product.
So it could be a product that that has many agents in it delivering a capability, but the software design paradigm of a of a of a program or an agent that does one thing very well, give it that kind of bounded scope to be able to control for that from a risk perspective.
That gives you then the ability to manage that as a as a team.
That notion of continuous beta, that the only time that something's out of beta is when it gets pulled out of production is something that I think it needs to be kind of uh considered kind of uh, you know, kind of core software engineering mechanic that we need to be able to apply as we go forward here.
You know, when you talk about OpenClaw and Multbot, you know, all these kind of uh, you know, agentic systems that are going to be kind of uh working in their own way, that's here.
You know, it's already here today.
So we need to be able to understand that our governance frameworks need to be able to evolve with that and our governance processes need to be able to uh evolve around that.
Some of our customers are like, hey, we we are only gonna make uh AI available for our engineering teams but not the larger organization I think that that's a mistake because the larger organization understanding that context understands kind of different risk profiles than just say a purely engineering perspective you know that that that kind of full kind of 360 view in that regard from a security standpoint I agree I think that there is a there's a lead into what's realistic from a security and and boundary perspective and then what is kind of like hype from a security perspective and that that's really aligned on what the agents can do and what we want them to do.
And I think that that constrains the kind of security boundaries that we should have I think about kind of like traditional security context, right?
Which would be like if I'm doing you know NIST 853 security stuff or SOX compliance and those things how am I building AI into those kind of very highly regulated environments and I think it goes back to what you said, uh Thomas, which is getting the basics right, right?
Basic data protection, basic supply chain hygiene, basic um AI workflow hygiene.
Like those are the things that regardless of if you're going to be, you know, giving models to 90% of the developers, uh, if you got the basics done correctly that matches to normal AI use cases or non-AI use cases, if you're getting your supply chain right, you really if you got CICD right, so you got a point of of entry for all of those changes, you got those basics right.
Then you can layer on the different security concerns that are there, what your risk tolerance looks like, so that you can actually take advantage of AI in a very meaningful way that doesn't open you up to kind of these additional attack and threat vectors that are there.
So they the basics around risk modeling, around getting the basics on the engineering uh side right, having the right data protection strategies at a tactical level, I think that those things make it easy to start using AI, and where we see clients kind of going in a direction where they're you know having breaches or vulnerability is when they weren't doing those basics right, right?
Um, you know, I I think that that that that's I agree with your your context there on that, Thomas.
The threat vectors are real and they're emerging and they're gonna be constant and they're exploding.
So I think that when we think about our own uh CISO organization and are working with our customers, uh CISO organizations, things like your DLP, your model management, your cloud architectures, your architectural standards, and so on and so forth.
Not having those as communicated practices is not a viable opportunity for uh an enterprise, you know.
So I think that those are kind of key critical as you kind of carry these things forward.
To reiterate that with a tactical example, whenever I'm seeing kind of like AI writing code or an AI, a new AI breach, it's never anything, it's very rarely a new exotic technique.
It's hey, the AI, you know, wrote some API keys in a GitHub repository and we weren't doing any checks uh in our CI pipeline for API keys or secrets secrets management.
Oh, it was, you know, it used a known CVE as an attack vector and it introduced that into you know a supply chain and we built that code and now it's in production.
I I think that there are some exotic you know attack vectors as a part of AI, but even things like the MCP call chains, it's yep, there was a basic man in the middle attack that we didn't actually have basic security hygiene over.
So I think getting those things correct really reduces the attack vector and the security concerns that you have, and then having basic risk management as a part of that process makes it really um easy to reduce the the attack vector, have you know very good security involved uh as a part of that, and then to effectively use AI where you really need to use it.
Well, we think about kind of this landscape, we have AI models versus applications that are consuming inference in that in that regard.
So there is this notion of model points.
So that is one of those things that you need to be able to understand is like, hey, if somebody's going to inject uh new rules to your to your agent, uh that those are really um, you know, kind of areas that need to be considered and kind of captured.
So good practices around, you know, policy as code, software bill of materials, you know, secure by design and your and your in your practices matter that much more because you know it it isn't it's gonna be one of these things that you built, left out there for a long time, and then all of a sudden now it's like you know, the the benefit previously was that agents had a small memory context.
Now, as you're starting to see that memory context get larger and you're starting to see them do things for longer periods of time that are more sophisticated or interacted with uh multiple agents, that just exponentially increases your threat vector.
So if you think about this as a notion of, you know, uh we were recently at an event and we were talking about this notion of how do you get agents to be able to control their contacts.
And one of the things we thought was like this is really a one of the really appropriate uses of ledger technologies when you think about you know agents writing the ledgers to be able to have their contacts.
So when the agent gets uh you know removed from the environment and they get reinstantiated in an ephemeral manner, they can get that context back and understand what it actually means to be able to run.
Or you could make a rule that says, hey, you have to establish new context at each time the the agent is reinstantiated in that regard.
So these are all ways in which the controls can be done.
And we learn these controls through other techniques, through other practices.
I think that what comes back is that you know, we were recently at an event.
Uh, Ken, you and I were recently, or all three of us were actually recently at an event where we saw the the practices around engineering that have been uh evangelized since object orientation over the last 30 years have become that much more uh important.
So the the old ways still matter.
Looking glass describes a shift where the human role goes from performing tasks to overseeing the behavior of intelligent systems.
And you know, Ricky, you've talked about developers becoming the curators of intelligence.
Um I'm curious again to both of you, you know, how does how does that work?
How do we get people that instead of thinking about their lines of code, they have to curate the intelligence of the system?
Anecdotally, one of the things that I am really excited about that that AI is doing within this particular space, is that it's making software development more look more like software engineering.
And what I mean by that is that now the developer is in the seat where the LLM will do anything.
We'll do anything that we tell it to do.
So it's now our job to impart the context of what we do and constrain the LLM.
So now there's this idea about constraint engineering as the key practice in utilizing LLMs as a as a as a developer.
As I'm helping to build out AI works platform pieces, as I'm using uh AI on my day-to-day, I really focus on uh my job as a software developer being constraining the LLM, understanding a nuts context about the problem that I want to solve, the architectural elements of it, all of the information that I need to go and impart on the LLM and constraining that through prompt loops, through uh detailed specifications, through all of the metadata that the LLM is going to need, constraining that problem enough so that it's it's going to do exactly or very close to exactly what I need it to do.
And that I think is something that's making software engineering more exciting for me, but I think it's going to put a lot of the burden on individual developers to understand the problem more from a prompting standpoint to from writing good prompts to understanding what I actually want the LLM to do.
That's going to take a lot more knowledge work than, you know, not to say that 90% of developers were doing this, but going to, you know, a slight like Stack Overflow or Googling how do I, how do I write a put you know a basic loop or how do I write a very specific algorithm and then copying and pasting that code.
So it makes it more engineering than kind of the toil work that's there.
And I think that for for software engineers, true software engineers, practitioners of the craft, that's a much more interesting outcome than all right.
I'm gonna go write a bunch of Python code to go do something.
It is not uncommon for me to have a conversation where somebody's like, oh, I have something running in the background that's figuring out this other problem.
So they're orchestrating it today.
So it's like that could be your recursor, they could be clawed, Gemini, OpenAI.
Doesn't really matter which one they're actually using.
But the thing is is that what we're starting to see is this notion of people orchestrating actions that they're now going to walk away, go do another thing.
We'll be in a meeting that's completely unrelated to that.
And they're like, oh, I'm gonna check and see if my code is actually updated for XYZ.
And I think that that's an example where you're now starting to see people overseeing action as opposed to necessarily being the individual contributor of it.
Um, you know, it's not uncommon for me to have a conversation with somebody that's wanting to modernize a system where none of the SMEs that built that system are still in the organization.
So that context around who wrote the code and why they wrote it a certain way has been lost into the the mists of time, you know, in the enterprise.
And now we're having to modernize that and develop that context over a set of components.
And very rarely are we doing that line by line uh manner.
What we're doing is we're understanding the context of that system, we'll understand the capabilities that they're doing, we're understanding what it means to be able to be behaviorally equivalent to the system that exists that they might not understand, or they might only understand it from a what that system is supposed to do for the enterprise.
And then as we then go and get to that equivalent state, we then have the ability to reimagine those things.
And what you start to see is this this as an orchestra uh a team of engineers orchestrating uh, you know, kind of step function capabilities that didn't exist.
So I would say that, you know, the reason why I made the comment about February is a pretty big month for uh AI is that we saw all of a sudden context windows increase, the ability to do this orchestration uh become significantly more complex.
We saw the notion of multi bot and open claw and agentic uh you know networks starting to kind of emerge in ways that we kind of envision from uh the notion of swarming technologies and you know, kind of nanotechnologies from the past.
But the thing is that you know, now we're actually seeing it realized in systems that uh, you know, are you know you could harness from an engineering standpoint.
I would say that don't sidecar open claw into your into your into your enterprise, but you should definitely experiment with it or have it in a you know kind of a uh an air gap or you know, some kind of control plane that you could actually do this.
But I think that there's very real benefits to understanding how these systems work.
And I think that they're they're gonna be part of our operating norm in the future.
I mean, if you think about kind of serverless architectures or function as a service or these things that we did in the past.
I would joke, I would be, you know, a year ago, I was talking about like functions as a service and RPA were kind of our first steps on to one understanding what agents would do.
And then we talked about a single agent system, and then we talked about agentic systems, and now we're talking about swarm-based agentic systems where the agents might be writing their own agents to do subfunctions and so on and so forth.
You know, uh, there's a rent a human site that agents can go get people to go do things for them now.
So, what we're seeing is this is a now uh an operating reality as opposed to science fiction.
So I think we'll we'll we'll end with the the Monday morning question.
So the actionable takeaway, and I'll start with you, Ricky.
Um, you know, someone's leading a platform engineering team.
What should they be investing in today to get ready for what's coming?
What's their action Monday morning?
The their action Monday morning are three things.
One, I I would say the the most critical thing that I'm seeing cause AI investment in platform engineering to fall down multiple times and time over, is not having, and it's very very mundane, not having rock solid CI CD.
It it it seems like it's it's would be very simple, but most of the organizations that I'm working with are struggling with consistent CI CD.
And the CI C D is kind of like the brains of the uh platform engineering effort on the developer platform side, and what we're seeing is the lack of consistent CI CD means that I can't apply agentic workflows as well.
Um, I don't have consistent developers, developer-centric golden paths.
Um, I can't test as well.
I can't shift capabilities and complexities down into the platform.
So if I were a plat, I am a running platform engineering team for both clients and internally, I would do like a very quick assessment of what is the state of my CICD.
Are developers complaining about super long build times?
Does it take into account release confidence?
Can I actually do release management as a part of that?
Because if not, I may get a mandate from my CPO that says, hey, are we doing AI stuff?
And it's going to fall over eventually.
So I think that that's one of the things that I would do.
I think the second thing that I would be doing is taking account of are we actually doing platform product thinking?
I think platform product thinking in particular provides the biggest amount of uplift from going from AI being just a tools investment to an actual enterprise-wide differentiator on the engineering side.
I think a lot of organizations start with this, start this AI journey on, hey, we did a bunch of GitHub co-pilot uh experiments, or we bought a bunch of cursor licenses, or we've given everybody anthropic keys, and then expect this, you know, creation of these 10x teams that are there.
And they're not really thinking about, okay, if if what is going to be the developer interface for those, what are some of the key friction points that I'm not going to be able to solve just by throwing tools at the problem?
So really having a robust platform product thinking um capability or platform product engineers as a part or plot platform product the managers as a part of your organization and treating that like it's a first cast class capability I think that that's extremely important and then the last thing that I would do on on that Monday morning is making sure that I have the right runtime to match the business capabilities that are there.
So there's an extreme amount of focus across all the cloud providers to maximize Kubernetes all of these exotic new runtimes that are there but make sure that you've got the ability to have those runtimes running and operating so that you can set up some of the things that Thomas talked about earlier on the AI op side on the security side having the right runtime components is extremely important.
So I would have a catalog of those runtime components so that I can ensure composability for not only my traditional engineering workloads but my AI agent tech workloads as well.
So I would do all of those things kind of at the beginning, at the middle, at the end.
Um, if there was one last fourth thing, making sure that I'm measuring some of the right things.
But those those three things are the big focus um that tactically that I see more and more clients kind of falling down on.
So Thomas, I'll give you a little bit bigger window because you know, if we're talking about a CTO or a VP of engineering, and by the way, feel free to respond to anything Ricky said as well.
But if we think about 2026, you know, because CTOs are more forward-looking in general, um, you know, what's the most important for thing for them to get right in this year?
So uh I think that one of the aspects is that you you a CTO can obviously think in their domain, but I think the ideal scenario is that they have a cross-domain use case that that is affecting one of their stakeholders, like an operations officer or marketing officer, so on and so forth.
Be able to get to a measurable 12 to 16 week pilot that you're going through and actually understanding what that means from a metric standpoint, what your controls are, you know, a contract first data product from that you're to to touch on your earlier approach, this notion of kind of policy as code being baked into that system.
And then we could do look at things like what does it mean to have automated policy enforcement, what is the scaling that they want to be able to go through in this the from an approach to this work, and then really at the uh I all of the things that are gonna come out is gonna be reuse, your quality standards, your way of managing and and governing a program like this, and then ultimately what are the evidence-based metrics that you're going to be able to go and say, all right, I now know what I'm gonna put into an environment.
If the CTO is looking only in their own domain, then they have the ability to control for what their engineering teams are doing, what their product-led organization is doing, and so on and so forth.
That very much, well, depending on their context, might be the appropriate way.
But I think the biggest unlock is as soon as you start to cross out of the CTO-only domain and start working with other stakeholders across the business.
So if you think about this, because that acquires a certain level of fluency or literacy around AI and it's likely a perishable condition for their career.
And on that note, uh that is a perfect close.
Um I want to thank Ricky and Thomas very much for the time.
I really appreciate the you know the the vision you give when you're right there talking to the clients and out at the events and so forth.
So thank you very much.
Perfect.
Thank you.
Thank you.