PurePerformance - 10x Engineers, 0.1x Platform: Scaling AI the Right Way with Michael Binzce_EP268 Michael Binz

Episode Date: September 14, 2026

What happens when your AI coding tools outpace your delivery platform? Andi Grabner and Brian Wilson find out with Michael Binz, DevRel for Juno - the Internal Developer Platform (IDP) at Dynatrace. Together they walk through the full journey of building an IDP that keeps up with AI-speed engineering. Juno serves as a knowledge base, automation hub, and organizational memory across the entire software delivery lifecycle. If your platform can't scale with your AI ambitions, your 10x engineers are working on a 0.1x foundation. This episode shows you what to do about it.Links we discussed:Michaels LinkedIn: https://www.linkedin.com/in/michael-binz-a1307a111/YouTube Video of their talk: https://www.youtube.com/watch?v=3Ow9rIdv-x8Bluebox: https://www.bluebox.ai Max Headroom: https://www.youtube.com/watch?v=egCOO7Zzq0U

It's time for Pure Performance. Get your stopwatches ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson. And as always I have with me my fantastic co-host, Andy Grabner. Hey Andy, how are you doing today? I'm feeling good, but as you may have noticed, I didn't make any funny faces

because I know the video quality on your end might not be as good and you wouldn't even see my funny faces. No, I see all the video fine. So it's funny. You reminded me, so you were talking to, so Andy was telling me I'm choppy, right? So as I'm moving, right? And it reminded me of Max Hedroom. I don't know if anybody listening or if any of you all remember.

It started out as, I don't know if it started as a Coca-Cola advertising thing. It was like this in 1980s computer animation character. They were like, hey, blah, blah, right? And then they ended up making a TV show about him, like, converting, like there was a TV underground where like the big corporations took over and it was like this whole like cyberpunk kind of thing. But his head would be all like computer glitchy. Anyway, if we have any older listeners who aren't as young as you two, I'm sure they remember Max Hedrum. Look him up.

It's a pretty interesting backstory. But, you know, it was actually a character. It was actually an actor voicing Max. Max was not a living computer entity or an artificial intelligent one. People had to hand code it probably took a lot of work. And something that we want to probably try to avoid, I imagine. Yeah. And I think this is also a great segue.

This time you did an awesome job and trying to figure out how to get AI into the topic and into the conversation. AI. Ai, aye, aye, aye. It's all AI these days, right? Sorry, everybody, if you're sick of AI podcast. but now it's so today I wanted to welcome on the podcast I just welcomed him a week ago on my YouTube channel Michael Bintz who is at Defrail at Dinotrace but not outward facing like I typically do but more inward facing to enable our engineers at Dinah Trace to write better software

but I think it's much better if we hear it for Michael Michael thank you so much for being here and I think let's get quickly started about who you are. Also feel free to bring a little bit of background, like what you did before Dinotrace and what you now do with Dinotrace. And then I want to jump into the topic around how we scale Argentic Engineering at Dinah Trace to 2,000 plus engineers. Yes, hi. And thank you for having me here.

Yeah, as you already said, at Dinatrace, I'm doing an internal death rail role. So quite similar to what you are doing, Andy, but really, I mean, a little bit of a spoiler. We have an internal developer platform that helps us doing software engineering in the Argentic age. And we treat this as a product. So we treat this as an internal product. We're not selling it to the outside market. But we do realize that we need to listen to our users, understand their pain points, provide solutions to them.

And then we realized at the beginning of the year that we also have to invest into developer relations. So really making sure to explain to people what the platform can do for them. Again, hear their thoughts and feedback, bringing that back to the product teams, so to the internal developer platform product teams. And with that really, yeah, improving the platform every single day, make sure that it delivers the most value to our users. Yeah, and a little bit on background since you asked. So I am a software engineer by training.

I worked in large software companies before. I then went a little bit over the Scrammaster Agile side. I went into management. I did people management in software engineering. I had a little detour where I actually worked in product-related roles. Last stop there before I joined Dinah Trace was actually an outbound product management role. So also talking about the product and explaining it. to people.

And so this is interesting. It's a little bit of full circle now. Dinah Trace, I originally worked also as a people leader. We were responsible for the app and service delivery part of the platform. And yeah, now since half a year, I'm focusing on this internal communication side. Cool. Hey, and we just published a video. And folks, we will be adding a link to that video on YouTube to the description.

And also, Brian, which will make a note that we all. also add a video to what's his name again, Max Headroom? Yes, Max Hydro. Yes. Yeah, here we go. We also want to add everything we discussed today. Back in the days when I, when I think in the 80s, we had two channels in Austria. Oh, no, no, no.

The channel 23 was the TV station that they were running their covert operations out of. Ah, okay, got it. This clearly tells you that I have never heard about this, but it will be something for me to catch up. what, 10 years? I got 10 years on you or something. Yeah, something like that, yeah. Hey, but back to the topic. So we did a recording because I really found it fascinating the platform engineering journey that we went through,

especially in the last year or so since Agentic AI took off. Michael, you mentioned that we are treating a platform as an internal product. Funny enough, when I co-authored a book on a platform engineering for architects, so crafting platform as a product and this was like we published it two years ago and the AI was just getting started but I wanted to ask you platform engineering is something that

many organizations have done over the last years it's around making it easier for engineers by providing self-services to kind of avoid the complexity of every engineer having to become an expert in how do I set up Kubernetes, how do I configure my DNS, how do I configure my network, how do I get a database? And so I think platform engineering took a lot of this, away this complexity.

What is it now? What does platform engineering look like, though, in the age of AI? This is for me an interesting question. I wanted to understand from you, yeah, what happened in the last year or so, because I know we had a platform, we also had internal platforms before. Yeah, definitely. I think it's a really interesting journey also for me personally. I remember when the whole AI agentic engineering hype really started to hit us also in Dinah Trace.

I remember that the first thought was, how can we use AI to improve the platform? So we had a whole bunch of platform use cases, right? As you mentioned, abstracting the complexity away from people so that they don't have to know all of the stuff. And we knew we had a long list of use cases and journeys that we wanted to support what we did, but we never get around to actually build that for them. So investing in a platform is a lot of effort. We talk about quite technical details that you need to encode. You need to provide proper API abstractions and really have solid services in the background.

And this is a lot of effort. And so our first thought was, how can we leverage AI to improve this? So can we just speed up development for the platform, right? Just build more features into the platform faster. Or I remember an architect said, maybe we can also just skip the platform at some parts and just give users like AI agents that would just do things natively in Kubernetes or something like that. And it took me a long time to realize that it's not, I mean, yes, the question is relevant.

How can we use AI to build the platform? platform faster, right? But the fact that the platform itself is an essential piece to making engineering of our product faster. So the platform itself is needed to become faster in engineering in the gigantic age more than ever. And it took me a while to realize that. And it was really when we started integrating things like skills and AI configurations, into our platform as first-class citizens, this is kind of very clicked for me, and it became very clear,

aha, it's the same problem we always had. The platforms try to solve a knowledge problem, as you said. You cannot expect the 2,000 engineers know everything in the entire CICD stack, right? You cannot assume that 2,000 engineers know about every single detail of this complex product that we're building, all of the different cloud stacks, technologies, configurations, And this knowledge problem, to solve this knowledge problem, we can actually use the platform.

And yeah, this was really interesting for me. And this is where I think a lot of things clicked for us. And I mean, I found it also fascinating when we talked about this in the video, because you also highlighted that the knowledge base that we have is kind of core and centered. to that platform for the benefit of the human, but also the benefit of the AI. Because when we ask an agent, you know, do XYC for me, then the agent like the human can understand what components are available, what are our templates, who is owning what. There's a knowledge base that is now that is central to a platform.

But let me ask you a question. We always had knowledge bases, right? We always had things documented in SharePoint or in. in Confluence or in other platforms. Is this just now an index on top of those existing document stores or is this something else? Do we need to migrate or to update the knowledge base to be more AI friendly? Yeah. So I mean, I don't know if this is true for every single larger or

But even if you have these existing knowledge sources and you mentioned SharePoint and we have other actually a number of tools where we have knowledge centralized, it's always been a challenge to find stuff. Even before the gigantic age, it's never been as easy as to say, I just Google this or I just search in a central search and I get relevant search results. Because first of all, it's various sources, right, as you said, and I think it's hard to unify this. I don't let me know if anybody managed to do this in a large scale. I haven't seen it so far. You have the problem of outdated data. So there's lots of stuff lying around that has been written by somebody three years ago and then they did something else.

And so you also have stale information, right? The traditional search engines just produce bad results. Again, also missing a little bit the feedback cycle, what is still relevant, what not. So we always had this challenge. And it was actually one of the first use cases that we wanted to build the platform precisely to solve that challenge. Even before, again, before Argentic engineering became a thing, we wanted to have a single source of truth. And this meant that we built up our own software catalog, a new technology, that not just handled the data and the information, but also the... relationship between things. So this is the software catalog, the catalog information.

So basically metadata, meta data, right? To understand how things relate to each other. And this is curated and it's manual work to do that, yes, but we realize that we need to do this if we really want to manage this information at scale. And then once it became clear that we're building this knowledge base, not just for us humans, but also for agents. We basically threw on top a rag pipeline and attached an MCP server, basically.

And with that, all our agents have access to the same knowledge space. It's funny how simply you made it sound, right? I mean, I've been playing a little bit more with AI for work and I've just been looking at some stuff

trying to figure out if there's any use for doing a private AI in my home office, in my home lab, and I'm trying to understand all these different concepts. You're just like, Spinoi, we just did this, this, and this. And I'm like, yeah, I've seen a lot of those words. But like, in such a short time for people who are using it, it's become second nature. So it just cracked me up that it's.

Yeah, no, absolutely. And I can relate to that because not that long ago, I had the exact same feeling. Yeah. And I remember we had some, I think it was some innovation day some time ago where somebody out of fun they added like an AI system like a traditional chat to an existing product right and said

look now you can chat with it and it was eye-opening because it was clear that this technology is actually available and it's not rocket science right I think if you have a subscription to any

not even state of the art model anymore a decent engineer will be able to set up something like that I think what's special for us is that we had the underlying foundation already in place. We did have the catalog, we did have the knowledge source in place. It was there, right? Yeah. And basically just that's why I said we just threw this on top. I mean, obviously there were smart engineers working on this so that this is also enterprise scale and secure, and

we have the governance topics covered, right? So there is some, especially in an organization like Dinah Trace, which is on the stock market, there are some things you have to consider. So it's It's not that simple as I made it sound. But overall, what we had to add on top of the existing knowledge base was a fairly thin layer. And we immediately were able to show everybody in the organization the value that this data has because now they hook up their agents and they get answers that are much more grounded in reality. And yeah, that was really, really nice to see.

What I also really like is even though I don't actively code anymore at Tynetries, so I'm not part of any of the development teams, but I use on a regular basis your Juno integration with Slack. So we're using Slack internally. And one of the use cases that I use it for, so I've been here for a while, right? So I have a lot of tribal knowledge in my head because I know people from the beginning, but the organization is changing so fast. So I was always able to say, hey, who is the PM for this particular feature?

And I knew it. People were also asking me from my team. but as we are growing and growing and people are moving around it's getting harder and harder and so one of the things that I use I just ask Juno in Slack hey can you tell me

who is responsible for this particular capability because I need some answer where do I find information then you also showed in the videos he did some live demos where you were able or an engineer can ask about scorecards right like how is my

component currently doing where is it deployed helped me understand how I can improve the quality so that I can make my quality gate so I can actually deploy it into production. Give me code recommendations on how to fix this problem.

And for me, this is just phenomenal, right? Because it's impossible to know everything. It's impossible to spend the time to first read 50 documents and 45 of them might be outdated and then understand how to do this. Absolutely. I mean, since you bring up the scorecard,

But I remember not at Dinotrace, but my previous job, just understanding the quality requirements is difficult. Just understanding what you need to do to actually bring it to production in a large software company is not trivial. And then you might know somebody, right? You might know the quality engineering manager, right? And you might talk to them and they help you. And then we have quality departments, right, in the old days that actually manage this.

And it was a lot of human effort to get it done. And so, Juno, the, so our internal developer platform doesn't just solve it by making the information available, right? So again, just basic quality standards are documented, right? So we have that in our platform, great. But we also invested in the scorecard. And the scorecard is a Dinatrice app, and I think it's still only internal, if I'm not mistaken and it actually has encoded quality signals so everybody can simply go to

the app and sees visually where is my where's my application doing in terms of a defined set of quality signals and that's I can also use an API to get the same information right or nowadays I can use any agent any coding agent clot code or GitHub co-pilot or whatever hook it up to the same system and I get a correct answer on the quality signals that are relevant for us. And so I think it also shows nicely that we're still investing in the platform foundational layers. We're still investing into providing an API that provides that data. That has nothing to do with an LLM output, right?

But this is deterministic data based on quality signals that we care about. And so we're investing in that and then we make it available to everyone, to humans, via the app or to agents via the Juno portal and platform. Do you see, because you mentioned we have UIs for certain things, do you see a trend away from UIs because why would you need to build an UI for everything if you can just ask your agent and then the agent figures out how to best present the data to you? Yeah. Yes, I do see a trend. Our product manager, so Robert Bauer is the product manager for Juno.

And I remember, so we create features for the platform at a quite high pace. So there's constantly new features coming out. And the engineers that are building that are also building new user interfaces. So even if it's just like managing agents, there is at least a terminal UI or some kind of on the console level way to configure it and interact with it. But because it's cheap these days, we also get new user interfaces like graphical user interfaces,

web interfaces, to also configure that because why not? We have the ability to create this. But because it's an internal product, we actually don't heavily invest in the look and feel. We don't heavily invest into classic UX, right?

But this creates a problem. So now we have, from the top of my mind, I think we have three or for new user interfaces that we created in the past months. And they don't quite look the same and have all a little bit of a different feel. And so I asked Robert a few days ago, shouldn't we maybe do a UX review, look at this, maybe we can simplify? And he said, yeah, but there is an assistant built in.

I'm not using the web interface anymore. I can just open the assistant and talk to the assistant to configure the platform. And so it's really, really, really, hard these days to argue into investing into graphical user interfaces because the experience that people have with just talking with their agents to well-defined APIs is so much better in many ways. I still think there is always a place for some kind of user interface. I think you need to understand what's a use case and what's the best way to serve it.

Dynetraise is a great example. I will always like to see charts. I will always like to see data in a graphical way because I think that helps me. I still honestly don't go a lot to diner. So we use diner trace for self-monitoring. I usually use my agent, so my cloth, I'm hooked up to diner trace to do the regular reports that I'm doing. I'm not that often going to the dashboard, but when I want to present it, I always go back,

I always go back into diner trace and use the amazing dashboard features we have because we're people and we like visual representations of data. Yeah, I think the argument always for having that interface, though, is twofold. Number one is if you need to intercede, you need to have that ability to do so. We're nowhere near the point where we can hand overall trust to the AI, right? We've talked about, you know, Andy, you know, machine level language for programming AI, right? But there always has to be some extra abstraction layer for human interaction. But also, I think, you know, from a security standpoint, it's going to prevent you from being taken hostage by the AI companies themselves, right?

As soon as they triple or quadruple the price of tokens, if you don't have an interface or don't know how to use it anymore, you're done, you know. And that could quickly sink in companies' finances, as we've seen. It was just just even fun accidents like Uber had recently, right, where they're like, oh, let's just spend everything, right? but it's easy to say, yeah, it's easy to say there's not much use case, but it's more of like the, well, what's our backup plan? What's our exit strategy? Absolutely. I actually would slightly correct my statement.

We are building user interfaces still, right? So we are building console or terminal UI user interfaces or things that you would do in the terminal. It's still a user interface, right? And in general, I think it's a good idea to think about what we're building. Would it also work without any agents involved? Right, right. And if the answer is yes, this is useful also for humans, then I think that's a good indicator that it's the right investment.

Yeah, you know, it's interesting because I was actually talking with a colleague yesterday, and I mentioned this idea that, you know, but I know people might freak out when I say this. I kind of feel like Kubernetes is getting near end of life, but what I mean by that is Kubernetes as we know it, right? It used to be this thing that you could take off the shelf, pop it in, run it, and now if you look at any Kubernetes stack, it's so highly customized.

There's so many different pieces to it that the Kubernetes piece is just part of a larger component, and everyone's really going towards platform design, right? And it goes back to what I've been talking about a lot, Andy, as well, with the idea of like everyone's trying to eventually, and I think you guys kind of hit on this without mentioning it in the, in your recording the other day, everyone seems to be trying to recreate what Cloud Foundry was doing years ago.

The opinionated platform have everything just there and ready to go. And that got me thinking, like, the platform of the future doesn't need to be built for humans. Right? It's like an AI first platform that needs the human abstraction layer.

But, like, when we talk about designing a future platform, just like code doesn't theoretically have to be written in human language, a platform doesn't need to be designed to operate for a human conceptual. Obviously, you would want that layer to access it and control it there. But again, if I'm running code, I don't care if it's going to be run as a function, as a container, as a VM, whatever. If one of these, like, AWS or something just said, you know, here's our updated version of what Cloud Foundry was.

Give us your code and we're going to run it. We're going to AI is going to analyze it. pick out the best technology to run it on and run it in there. I think that's really all that matters in the end. But everyone's trying to also build these same things. The idea of platform engineering, I think, is

in tandem in parallel with all of those, right? Yeah. Yeah, it's an interesting thought. So if I wanted to quickly, Michael, one more thing and I know, Brian, we also see this. You said, it's so

easy, it became so easy to create a new on top of an API. I mean, you said you built multiple UIs for essentially doing similar things. Also, Brian, we in Dinahries, we have a lot of internal colleagues in sales engineering that are currently building Dinanries apps like crazy. Same app over and over again. Same app over and over again. And I think this is the big challenge we need to solve because in the end, if you have a great API,

it's a foundational layer that the AI can consume. And if you're then building multiple different versions of an UI, because I just like it in a different flavor, then we end up with a very bad user experience, especially for new people that onboard, and then they will ask, so what screen shall I use for X, Y, and C? And then you can say,

whoa, you can pick from five different versions that we've built over the last month. Yeah, I couldn't agree more. We have themes, right? Yeah. I think, I mean, just because you mentioned onboarding, is another interesting thing we looked into how do we want to onboard our engineers to the platform. And also here, the idea was that we would do this in an agentic way, right?

We make sure we have the Juno assistant that can just help them in their own boarding journey. But I think there is something that came to my mind that a graphical use interface or a web interface, a web portal does that I think the other agentic way can. cannot handle. And that is just, I think it's still, and maybe this changes, but today it's a way also to build trust. So if I can go in as a human and I go to the portal and I can actually click around and explore, this is a different way of exploration than I would do with a coding agent.

And I think this helps me to trust that there is reasonable data in there. It helps me also to gain an understanding of how good the quality is and so on. And so again, we are humans. I think we are building all of these for humans at the moment, right? Even if we say that agents work with the platform and get things done, they do it on behalf of humans, right? Still the humans that are ultimately accountable. So I think there's an element and an argument for having user interfaces that are graphical

for humans. And just to make sure that my point wasn't, so just to clarify that point, we are building an internal developer platform that is internal, it's not a product that we sell. And it's super dynamic. So I do expect that once we know the feature set of the platform is fairly stable around the set of functionalities, I do think we will invest into user interfaces here as well. I just think that for the more technical aspects of the platform right now, it hasn't really. really pay, yeah, it hasn't been a focus for us. For the listeners that are

watching the recording at around minute 11, 12, Michael goes into explaining the architecture of the platform. And at about minute 13 or 14, there's the full thing

drawn out with the software catalog and knowledge graph in the center, the agents and also on top. And I really like this the way you have kind of phrased it. You have the portal. There's still a portal in Juneau. This is where you can find things, where you can explore things,

like which software components do we have? What are the dependencies? Where's the code? Then you have the agentic workspace, and you sub-labeled it with two things on your machine. And then you have integrations and triggers where you're getting the agents to work for you, because you are attaching an agency.

agent to a pull request and have it do a certain thing for you for certain pull requests in certain branches, for instance. So I think this is a really nice architectural overview. Also, everything, as you mentioned earlier, is observed by Dinotrace. So we're monitoring the platform. And this is maybe the other topic that I would like to ask you, because this has always been a challenging question that I get. How do you measure the impact that you have?

with your work. How do you measure the impact that we have with Juno? Do you know you are on the right track? And I was just curious if you can say a couple of words on that. Yeah, sure. So, I mean, I think we, in this overview picture, in this diagram, it says observability, yes, we are using diner trace obviously because it's free for us to use, right? But it really works with any observability solution. And I think observability, Observability in the genetic age is absolutely key. So if you're building, if you're shipping software faster than ever, you need to understand what's really happening on your real systems.

It's absolutely crucial. And so we at the Juno development team, we've always used observability as a really from day one. So we always thought about how can we measure the usage of what the thing that we're building here and how do we measure success? How do we track if you're on, yeah, how do we track adoption to see if people are using it at all and how do we track if, so the, just technical correctness, right? So it always has two things, the technical correctness, so making sure that it works and runs

and if there's an issue, we can remediate it quickly. And on the other side, the more the business user facing questions, how are they using it? Are they getting their journeys done, right? which of the features are they using more or less? And so to abstract it a little bit away from the component level, we're basically tracking adoption. So for us it's quite simple. We understand our total market better than anyone else because it's an internal product.

We know it's 2,200 people in R&D. We say that we have about 2,000 engineers. So we know that our goal is that 2,000 people are using the platform. every week. And now we can simply measure how many people are actually using it on a daily basis. We track this on a daily basis, on the weekly basis, on a monthly basis. And with this, we get an understanding, are we increasing adoption? And the other thing is then, of course, the only thing that really matters is can we move the metrics that matter for a software engineering company? And so here we didn't reinvent the wheel. We have the traditional metrics around

the Dora framework, for example, that we are tracking. And I think one of the things that we also mentioned in the video, it's also nice to see that we can really ship new and innovative ideas from the first idea to actually market. And yeah, that's basically what we measure. Yeah, you brought up the use case of Blue Box in the video. The Blue Box was also completely created from scratch. leveraging the new platform. That's fascinating.

And folks, I can really encourage you to watch that video. You also went into some of the dashboards that you're using where you showed the adoption. You also showed which type of skills are being used. I mean, we had to cleanse over it and also had to remove some confidential information. So that section got a little shorter. But still, you see that this is all. possible. And as you correctly said, the underlying foundation is all open telemetry.

That means everything is instrumented with open telemetry. We happen to use dinah trace, obviously, but the power of these standards make it possible that you can instrument every single agentic conversation that an engineer has or that is triggered by any type of integration. So we know which model, which skill. Also for me, this is something where maybe you want to spend a word on, marketplace. skill marketplaces, skills can also come from different marketplaces, how does they work? Yeah, this has been at the beginning of our, let's say, more accelerated adoption of Argentine engineering practices. We realized that everybody was talking about skills and plugins and agents

and whatnot. And we quickly realized that we need to steer this conversation or facilitate that conversation basically also curated in the end so we did a little bit of a journey we started with okay let's share everything we have right we used also Juno here for that and we said okay there's a there's a repository just add your skills there right you can use the central repository it's our our community marketplace if you want you can also if you have a written existing repository where you manage your skills you can simply onboard that also to the Juno platform in a very easy way

And with does make it available for everyone, right? So we really encourage people to share whatever they are doing. And it was really incredible in only a few weeks we had 200 skills that people contributed where they thought, I built something here that I think is valuable to the entire organization. And then we realized, at this point, we realized, okay, 200 is a large number. I have no idea what is in there anymore. We actually do have to talk about curation as well. We do have to talk about what is like an officially-chon-

support that skill that will help you that most likely every engineer will need at some point in their journey and on the other side what are community skills that might be useful to some but are certainly of a different quality standard and so this is where we then separate different marketplaces now of course we also have the dinatrice marketplace itself so there's a dinah trace marketplace for the official dinah trace skills to use dinah trace and yeah that's basically how we organize it. I want to, Brian,

I cut you off earlier and I'm sorry. That's all right. I was just going to make a small point of like, you know, you're talking about all the different interfaces and all the different apps like this on the internal side, right? It seems like as people

and companies are going ahead and creating all these little internal apps for everybody to use, there needs to be, you know, for the public's facing side, there's always like a style guide and an interface guide, all that kind of stuff, right? And it feels like that has to get brought over to here, have a central repository for everything.

So like, hey, if you're going to build something, it goes into a central repository, and then I'm sure you could probably even use AI in some level to make sure it's adhering to the, you know, use skills to make sure it does the style guide and goes through and looks for duplicates, right? And then contacts everybody. Like if there's like 10 versions, the one thing,

like, hey, everybody, you're all working on the same thing. why don't you all put your ideas together into one but that would be I think you know it's interesting because I think the productivity that AI allows the employees to create all these apps for themselves

ends up taking a lot of their time away as well because instead of one person creating you got 20 people creating the same thing and that's a lot of wasted time then Right. So unless you can manage that, the gains that you're getting from that productivity might get lost in replicating what's already been done. Absolutely.

I have two thoughts coming to my mind based on that. The one is I mentioned that we took us a while to realize the value and the benefit that the platform has to everyone on this journey. It was during a time where lots of people had the same challenges with, sharing knowledge. Everybody understood context engineering is a thing. Everybody understood, okay, we need to feed our agents now with curated information, right? So many people started working on something that was similar to what we did already, right? So we had this challenge that we didn't have one platform at Dinotrays, but we had multiple emerging platforms that did something similar. And so that's actually also around the time where we realized we need internal

death rel to talk about what we're doing because people don't know. And they don't do it, they don't duplicate the work or they don't find competing solutions because they're bored, but because they have a real challenge, right? And they just didn't know that there is somebody working on it. So everybody we talked to are saying, yeah, great that you're doing that. I can drop this now. I guess it's fine. I wait a few weeks or usually it's not even weeks until you get it done and then I can use

it. So absolutely. Duplicate work is an issue and one way to address it, so one way how we addressed it, was to actively talk about it very, very openly of what we have planned and what we are capable of doing. And the other thought, I think it's more important than ever to pause a moment and think about, is it worth building it? Because building is became so, I don't want to say cheap, because I think we all realize it's actually not that cheap.

for the full life cycle. But the initial hurdle is so low. You get so fast to a first version, right? So really pausing and considering, is it worth building that, is absolutely crucial these days. Yeah. I feel that one too,

because it's like, oh, maybe I should build something for this. Maybe I should build something for that. I'm like, well, you got to ask, like, going back, Andy, to that idea from a few years ago, Ilsomar for automation,

find something you do repeatedly and automate it. its first question is like, should this, is this something I do repeatedly? Right? Or is this like, there needs to be like some sort of commandments for like what's good to build something for?

Yeah. And also they don't just jump into it, but first figure out if this has already been built. I think this is the, because now everybody can easily automate everything. And the question is to we then have five different automation things that somebody AI engineered that now needs to be,

maintained. Yeah. That's the hard part because people have it everywhere. Exactly. That's the hard part. Yeah. Hey, to kind of bring it to an end here, I really want to encourage everybody again to watch the video.

There's two or three things. I think I had, I also promoted this on LinkedIn and I had two kind of quotes from you that I thought were really amazing. One was, it's it was never a coding issue.

It was a platform issue. And then the other thing is a 10x engineer that sits on a 0.1X platform still is just a 1X engineer. So that means you need to invest in the platform that then allows all of your engineers to become more productive.

And I thought that was really some really interesting takeaways from your talk. Michael, what's next? Any things that you're working on or anything where you said, hey, if I could go back to the beginning half a year ago, this is what I would have done differently? Any kind of like things for our listeners if they are at the beginning of their journey? I think would we have done something differently?

I think maybe sooner. I think the vision and the direction was very good. And once we saw traction, so with that I mean we saw adoption, we saw positive feedback, we saw people accepting that, not because we force it down their throats, but because they're actually asking for it and want more, we really started to speed up, right? We ramp up the team. If I would have known that we have this traction and market fit, then we could have started a year earlier, right?

So this confidence in the strategy, I think, is something that I would love anybody to have. And with this, maybe just to summarize, what are the core building blocks that I think are valuable, regardless of agentic engineering and how much it's going to be a topic for you? I think it is the investment into the platform. It is the investments into the knowledge layer. And with this, I think you cannot go wrong, really. But this also means that you have to have an understanding of the pain points, where they are right now, for a year. your individual situation, right, in your organization. Don't just adopt some third-party platform and think everything will be good.

I don't think that's how it works. But you really need to understand where are the users, which pain points do they have and then solve them for them. And, yeah, looking forward, I mean, by nature of this thing, I always like to, obviously, I want to make it look like we have this all figured out, right? I also say this in the video. The truth is we don't have it all figured out. There's many details that we're on the way. of getting done.

And I would just really like to learn also from people out there, how they are approaching it. If they have learnings that they want to share, we're still also in the process of scaling the whole platform to really all the teams, right? So there are still, Dinotry is a complex product. So we're still taking step by step to really make sure that we reach and solve all of these pain points I just mentioned. But yeah, I think having trust and believing in that strategy early on, I think is a good thing. Brian, any final thoughts from you?

No, I had all my thoughts during the show. You can tell I always go on a rant when I do. I think, you know, the only thing I can think to say is, you know, it's funny we, my comment in the beginning was like, oh, we're having another AI discussion, but it's obvious that, you know, there's so much to uncover, right? There's absolutely so many different aspects to think of. And it's fantastic that, you know, Michael you and Andy put together that webinar the other day and you're here to talk about it today

because it's not going away at least any time soon and we're starting to see the complications arise right? I think we even weren't we joking recently Andy or didn't it come up already like the N plus one issue with AI already pop it in right? So we know as we started it seems

very nice and easy to adopt in the beginning but then as you start really thinking about like oh how are we doing this and what's the implications of it all? That's when when all the wards come out and we have to take a step back and think like, we have to plan this properly, we have to set up guardrails, we need to set up processes. So it's interesting to see this all starting to unfold as people get more mature, and it's fantastic that people are sharing it.

So I think that's my final comment. Cool. Michael, I wish you all the best with the next steps on the platform, because I also know this will benefit all of us because we all work in the same company. I also hope you are sharing both the video and also this recording with all of your potential customers, internal customers, so that every developer that hasn't yet talked to you directly, they can listen to you and watch it on video, on YouTube,

or are you listening to the podcast? So yeah, and as we often say with guests, they always are on the journey, and I would love to have you back in a couple of months from now to see where the journey has taken you and what we can learn. Wonderful. Thank you so much again. It was really fun talking to you. Thank you. And thanks to all of our listeners. Thank you. Talk to you next week for two weeks.

Bye-bye.