Beyond AI Pilots: What Valiantys and Mercedes Can Teach Enterprise Leaders

[00:00:00] Scale your business with agentic AI with limited risk. With Denodo's AI data layer, your agents are provided with real-time company data and guardrails for company protection. Create the business you always dreamed of with Denodo. And you can do that by simply visiting denodo.com to learn more. But now back to my guest.

[00:00:23] What happens when one of the world's most iconic automotive brands discovers that becoming AI ready has far less to do with algorithms and much more to do with breaking down barriers between people, teams and data?

[00:00:42] I've got two great guests joining me today who together have been helping organizations modernize the way software is delivered, including supporting Mercedes on its journey towards becoming a more connected and AI ready enterprise. Now, whenever we hear stories about AI transformation, though, the headlines typically focus on the technology itself.

[00:01:05] But as you will hear today, the real work often happens much earlier. It starts with organizing information, improving collaboration, removing silos and creating the foundations. The foundations that allow AI to deliver meaningful results rather than becoming just another expensive experiment. So throughout our conversation today, I want to explore why so many organizations remain stuck in AI pilot mode.

[00:01:31] What separates successful deployments from endless proofs of concepts and paralysis analysis? And why clean, accessible, trustworthy data could be the most valuable asset that any company can possess right now? And if we have time, we'll also talk about agentic workflows, the changing role of software engineers and why AI should be viewed less as a replacement for human expertise and much more as a new colleague that is just joining the team.

[00:02:00] One that can work incredibly fast, but still needs guidance, context and direction. So whether you are a CIO, CTO, engineering leader or simply someone trying to understand where enterprise AI can create value. Today's conversation will give you practical lessons from engineers who are building these systems every day and helping some of the world's largest organizations prepare for what comes next.

[00:02:28] And if you're thinking, well, who are your guests today? Well, calm down. I'm going to introduce you to them right now. Well, thank you for joining me on the podcast today. I have not one, but two guests joining me to begin with Raymond. Raymond, can you tell everyone listening a little about who you are and what you do? Sure. Yeah, it's great to meet you. So my name is Raymond Omori. I've been with Valiantis for about five years, but I've been in software development for about 15.

[00:02:56] I'm currently the engineering manager at Valiantis and I just deal with all the custom development, which the projects that we're going to talk about today have a lot of that. So great to meet you again. You too, my friend. And also, like I said, we've got a second guest joining us today. Can you tell everyone listening about who you are too and what you do?

[00:03:17] I'm Ji Chang Dong. I'm a senior software engineer at Valiantis. I think I've been at Valiantis for over two years now. And before that, I was working at a pretty small startup. But yeah, I working with Raymond and the rest of the team on our custom development projects. And I've been pretty deep in work with Mercedes. Awesome. It's a pleasure to have you both join me today.

[00:03:44] I'm interested in both of your unique vantage points that you will bring to our conversation. And I think for people listening, when organizations talk about becoming AI ready, what does this actually mean in practice? And what are some of the challenges that Mercedes needed to address before AI could even begin delivering meaningful value? And one of the reasons I asked that question is, I think many businesses have gone AI first rather than problem first. We're over that now.

[00:04:11] But tell me a little bit more about how the challenges that Mercedes needed to address before beginning here. I guess, from my perspective, I think in practice, becoming AI ready is sort of about the data foundation under the AI.

[00:04:30] Because if you think about it, even from like a basic user experience perspective, interactions with an alum, right, you're paying for the inference latency and then any tool calls, retrieval round trips, stuff like that. And agents can fan out to a lot of different sub processes.

[00:04:50] So I would say the kind of single source of truth and the data foundation that an enterprise has must be performance and queryable and structured so that you can sort of pull the context that you need. And that was a lot of the work that was done with Mercedes. It wasn't really at the agent level. It was at that data level.

[00:05:11] Because agents can certainly handle disorganized context to some extent, but like long context is not a solved problem by any means. And obviously, the more tokens you put in, the higher costs, more latency, all these things end up kind of scaling badly. So for every disordered, dumb of context, you put in your kind of pain doubly on like the user cost and the final output.

[00:05:41] So I would say really making sure you are the foundation of your data is locked in and approaching it from that level is super important in terms of becoming an AI ready. And of course, Mercedes is not our only client. So we can, I can talk a little bit more about other clients and what it looked like for them. And I think the number one thing that I've seen is to be AI ready.

[00:06:10] What problems are you actually having? You know, what is the client actually struggling with? And where can AI help? Because too often, I think we see clients just activate to LGBT for all their users. And they just leave it at that, you know, and what problems are the users actually having? And how can we address those?

[00:06:36] You know, you might have a lot of content in one area, but we can't have to check institutions and slide art. We can't dump that all into the AI all at once. So what areas do we need to pull it in? How do we need to pull it in? How can we organize the data? And so on and so forth. It's a lot about approaching it from a more holistic perspective and what actually is needed for the organization. And just stay with that Mercedes project for a moment.

[00:07:06] And it focused on modernizing software delivery and reducing organizational silos, something that I think every organization has struggled with over the years. So what did the silos look like? And how did the team begin connecting people, processes and technology more effectively? Sounds like a real journey there. Yeah.

[00:07:27] Yeah, I'd say that with Mercedes, the sort of thing that stuck out with me is that in solving the kind of data foundation layer that you need to solve so that you can implement agents and LLMs and stuff like that, you are sort of also solving the kind of data silos that exist within your organization.

[00:07:50] Because you need to get the agent, the information that it needs in a structured, relatively deterministic retrieval. So you could use something like a knowledge graph, but any clean query layer is a lot more effective than just throwing an LLM at the mess and saying, yeah, we have dumped a bunch of context into this LLM and that's how we're solving the silo.

[00:08:14] Yeah, I think by sort of bringing all the data together in such a way that the LLM can reason over their full process of working, that also kind of natively solved the data silo issue in the same past. Because if you think about, hey, how are we going to give an LLM optimal context for a given task?

[00:08:40] It's sort of the same question as, hey, how do we figure out how these two different teams are going to share data in a way that gets them everything they need? It's sort of the same problem. So I think Mercedes kind of tackled them in the same past, so to speak.

[00:08:57] And Raymond, just to bring you in here from a leadership and transformation perspective, what lessons from the Mercedes journey or any client that you've recently worked with are relevant to any large enterprise that could be listening? Yeah, any large enterprise is going to have a lot of teams. And almost always, those teams are not going to be in constant communication with each other. There are exceptions, but in nine out of 10 cases, teams are going to be somewhat separated.

[00:09:25] They're going to have different concerns. And sometimes they have sensitive information as well. So there's a lot of data governance involved as well with AI. You can't just pull the data from other teams, right? You have to agree on what is needed.

[00:09:42] And then you're going to need to communicate across different teams to make sure everybody's on the same page in terms of what they need. Because again, what different teams need is also going to differ between different teams and organization. One team might be working a different way from another.

[00:10:03] The Mercedes team that we worked with was concerned with improving the work of other teams. So they're in a uniquely beneficial position to look at those teams. But in other organizations, that might not be the case. There might be one pilot team, for example, and they might work differently from other teams. So it's good to pull in as many teams as possible to get the largest possible view of what the organization is doing.

[00:10:31] And Ji Chang Dong, from your side, any lessons that stood out from the engineering point of view? Any big lessons you picked up along the way? I think from the engineering point of view, two things sort of came up most. And I guess the first is sort of pretty related to the second.

[00:10:52] So in terms of figuring out how to best integrate these agents and AI in general, you kind of have to know what good looks like. So like what your taste is in regards to that and those sorts of things in terms of ways of working. So it's kind of trying to find a point that you can evaluate versus and to do that, you also kind of need a clear vision of what to build towards.

[00:11:22] Like Raymond was sort of referencing, we were super fortunate with Mercedes and that the team we were working with was already very forward leaning in terms of tearing down silos and things like that. So they had a good idea of where they wanted to go, which I think was pretty critically important, especially because engineering work, I think, in general was kind of moving up in abstraction level.

[00:11:44] So if you think about like code at the deepest level, it's like zeros and ones, right? But no one works with zeros and ones. We all work at a higher abstraction level kind of beyond that.

[00:12:00] So with engineering, I think it's sort of centralizing onto the translation of like overall vision to requirements, the specification, and then from specification to code, you can kind of pull in LLMs at that level to really speed up that part of the implementation.

[00:12:19] But I think honestly, it's surprising how little engineering work has shifted in some, in a lot of cases, because that like vision to requirement to specification sort of thing where you're discussing trade-offs and all those other things are things we do all the time already. And then it's just from specification to code, that implementation step is where we can really leverage AI super powerfully.

[00:12:47] And I think it's fair to say that most organizations are experimenting with AI tools today, but many do struggle to move beyond isolated pilots often end up in pilot purgatory. So what is it you think separates companies that successfully operate operationalize AI from those that remain stuck in experimentation? What's holding them back? What are you saying here? I think there's like anything, a few factors at play.

[00:13:14] One is the organization actually needs to be solving a problem with a stakeholder because in truth, adding AI to an organization is expensive. The token calls are expensive. It's getting more and more expensive every day, in fact. And so you actually have to want to fix a problem.

[00:13:39] With a pilot, what we often see is you'll just have a team seeing how AI can improve what they're working on. But unless you have an actual problem that's costing the company money, it becomes hard to justify as a stakeholder to really create that AI solution.

[00:14:02] Not only do you need that problem that you're trying to solve, but you need to have a sort of a boxed section of work that you're trying to do with the AI because then that boxes in the cost. You can estimate how much something's going to cost as an organization, and that becomes easier. That makes it easier to get buy-in with the leadership of the organization to actually do that thing.

[00:14:27] So I think it is important with alignment and then also with having a project goal, like any project really, to have a successful AI implementation. And we do hear a lot about agentic AI and autonomous workflows.

[00:14:46] But I'm curious, how do you see engineering teams preparing for a future where AI agents become more active participants in software development and business operations? What are you seeing here? I'll be interested in what's working, what's not, and what you're seeing. What's happening? Is AI going to take your jobs?

[00:15:12] Is it going to, and if not, is it going to result in a situation where more and more is being asked of you to leverage AI and just do more work because AI is improving your efficiency? I think that is a little bit more of a short-sighted way to look at things. So the message that I've been trying to give is that it's just going to make your work easier. It's going to make it easier to do something better.

[00:15:41] If you have a limited amount of time, AI can really speed up your efficiency so you can actually build something better. It's not that you're cramming more projects in because you can do them faster just as sloppy with AI, but you can take one project and just do what you really wanted to do with AI just because it makes your work a lot faster. So I think quality of work can improve, and you're always going to need the engineer because,

[00:16:09] but as G-Chain was saying, it kind of changes the level that you're working at. So the AI is just writing the code. You still need to come in as an architect, a system architect, to understand, A, what people want, because the AI is never going to be able to invent what people want, and you're going to need to understand what you want the overall system to be so that the AI can build it. And we're always going to need engineers for that. Definitely agree with that.

[00:16:34] I think the sort of active participant thing you were mentioning, Neil, is kind of more, I think, to teams that are preparing well in the sense that they sort of view it less as, hey, AI is this tool. It's obviously a tool, right? But I think if you treat it a little more like you're onboarding a new kind of colleague, then it really helps in terms of building out the things that you need for AI to be successful.

[00:17:04] Because I guess if you think the LLM is stateless and kind of ephemeral point of inference, so it doesn't have memory in the same way we do. So I think you have to put this colleague that is a huge amount of crystallized knowledge and a huge amount of ability to implement into a situation that they can succeed in. So you have to ask yourself, what tools are we exposing to the LLM?

[00:17:32] Do we have provenance onto those tools? How they get called? Which get called? What are the failure rates? Do you have visibility into how context flows into each part of that system? And then can you reason over it? Because they don't carry memory. So you need a sort of inactive layer that gives you the appropriate level of statefulness for these agents to actually do their jobs.

[00:18:00] And I think teams that are really focused on that level of how are we going to integrate this sort of new type of colleague and how are we going to give them the tools to succeed are really sort of at the forefront in terms of properly integrating AI agents and other more autonomous workflows. And we did briefly mention a moment ago around the fear around jobs and AI replacing roles, et cetera.

[00:18:25] And I think we all need to continuously acquire new skills, keep learning and keep adapting. And as AI becomes embedded into daily workflows, I'm curious, how are software engineers roles? How are they changing and what skills are becoming even more valuable and which traditional responsibilities are evolving? What are you seeing in this particular role? I think that in general, the software development roles are moving upwards.

[00:18:55] So to become more of an architect, more of a senior, more of system design, that kind of thing. The challenge I think right now is with the more junior roles. And I think that the industry still tries to figure that out a little bit where the AI might has the potential to displace some junior roles where you're just coding, you know, you're just into code, writing code daily.

[00:19:21] The AI may chip away at some of those types of positions. But I think it's important to keep them in view and sort of change the very definition of that junior level position. Because if we don't continue to bring in junior talent, then when the seniors get old, we're not going to have anybody to replace them. So I think that is something that the industry is still trying to figure out today.

[00:19:47] From a day-to-day perspective, it's definitely, as I said before, and I guess Raymond has also sort of mentioned where as we move up an abstraction level, there's also sort of the seniority shift that accompanies that in terms of, I think, a lot of skills that engineers were using already are becoming more important.

[00:20:14] So it's sort of like shifting that load from how exactly are we going to implement the code from a line-by-line perspective to how are we going to discuss trade-offs, scope a problem, and interface with a client or a stakeholder and say, how are we going to translate your vision and your requirements into a tractable problem and scope?

[00:20:44] So I think those are things that engineers have already been doing for a long time. And it's just becoming a larger fixture of the job versus the round-level kind of implementation. And I think there's an important role that the engineer plays in terms of understanding what parts of the system are load-bearing, what parts of the system cannot change,

[00:21:12] because agents often have a very localized context of what they're doing. So they will happily knock down a wall to make a door and would really rather they not knock down certain particular walls. So I think that's a big part of these skills and the sort of way of working that's been coming up a lot more. One more thing on that note, actually. One more thing on that note, my favorite thing to say is AI is going to replace all the human

[00:21:40] workers once we can get perfect requirements. But, you know, that's never going to happen. So a big part of an engineer's job is to gather requirements, iterate on requirements and figure out what we're actually doing. And that's going to be more and more important. Yeah, completely agree. Another area we've got to cover, of course, today is data quality, governance, and trust. All areas that continue to be the cause of major concerns in enterprise AI.

[00:22:09] So from everything that you've both been working on here, what foundations need to be in place before organizations can confidently scale those AI initiatives, knowing that they've covered these concerns? I think that a lot of organizations have huge amounts of data just out there through many years of work. Mercedes, for sure, has terabytes of data just sitting out there on AWS.

[00:22:35] And so a big challenge is not lack of information. There's plenty of information. There's millions of documents in corporations. SharePoints. It's distilling that information into what is actually needed. There's another client where we wanted to connect their SharePoint, but there were probably 10 million documents in there over the course, that were gathered over the course of 30 years.

[00:23:05] And so we can't just give that to the AI and expect it to work. And a lot of it is not useful information either. You'll often hear the praise garbage in, garbage out. If you just feed the AI whatever, it's just going to give you whatever back. So understanding the shape of the data and organizing it in a more useful manner, I think is a huge challenge. And it depends on the organization as well.

[00:23:31] For which cities, I know we've built a system to track attachments and that level of data, excuse me, track attachments as they relate to issues. So then the flow, you know, theoretically the flow could be something like AI would be looking at issues and then it would pull attachments relevant to those issues. That's kind of a concrete example. Instead of just giving it the entire data store and expecting it to work.

[00:24:00] I think ownership is also a big part of it in terms of how are you able to access your data in a way that's fast and performance and on demand. Because if you're kind of at the whim of a given API or something else like that, that you don't own and control, you're going to have issues with latency, issues with even accessing the data potentially.

[00:24:23] So I think creating a kind of centralized layer where you can reliably get the data you need is very important. And it's a lot of times that's a huge undertaking, obviously, but I think that's the connective tool work that you need to do to be able to sort of work with LLMs at scale.

[00:24:45] And to also sort of assign your own sort of retrieval so that you can actually properly do governance in a way that says we're exposing the LLM to the information it needs, not more information that is not available to this team or another team. I feel like sort of the ownership of the data and the data retrieval layers becoming super important.

[00:25:13] And there's a lot of hype at the moment around AI tools in software development and vibe coding, for example. So if we were to look specifically at developer productivity, where are you seeing the biggest gains from AI-assisted engineering today? And where does human expertise remain so essential? I think sort of continuing the thread that's been going through this whole conversation, I'd say the biggest gains are at that implementation level.

[00:25:42] But to successfully implement, you need to have a well-specified idea. And to get a well-specified idea, you have to understand requirements. You have to be able to translate requirements to that specification. And then the agents can sort of step in and say, okay, here's how we're going to implement. And human expertise starts sort of upfront in terms of translating requirements. But also at the endpoint, you have to evaluate,

[00:26:11] you have to be able to evaluate the outputs in the context of like deep domain knowledge that a model may not have for your specific domain. A lot of automotive specific things are not deeply encoded into a lot of these models. And LLMs, the kind of reinforcement learning and other training methods that flow into them, make them aggressive averagers, I would say. So if your implementation and what you're doing is not average,

[00:26:41] you're going to have to have that human element to hold their implementation away from that sort of centralizing kind of gravity. And finally, Raymond, if a CIO, CTO, or engineering leader is listening to our conversation today, they want to feel a bit inspired, want to build a more connected AI-enabled organization. Any practical steps that they should be taking over the next six to 12 months to finally get up and running? Any advice you'd pass down?

[00:27:11] Well, first of all, six to 12 months is a long time in AI development. And everything's changing so fast. But I think I would, going back to what I was talking about earlier, really try to understand what people are struggling with. You know, look for things, look for phrases like, oh, we really want to do this, we'd like to do it this way, but we just don't have the time. Or the right way to do it would be this way, but that's just not practical right now.

[00:27:36] You know, phrases like that are, I think, sort of gold mines for things that can be improved or solved with AI. I understand what problems there are, understand where people are struggling, and then talk to your domain experts about how AI can help that. And I think there's always going to be, or often I should say, going to be some kind of great solution that could be built. Awesome.

[00:28:04] I think that is a perfect moment to end on. And for anyone listening who would like to learn anything, learn more about anything we talked about today from the Mercedes project to other clients, to just your work and how you're helping people. Where would you like me to point everyone listening? Yeah. So if people are looking for that AI domain expert, then definitely check out valiantus.com. And we also have a LinkedIn. And we'd love to hear from you. Awesome.

[00:28:33] I'll add links to the website, everything we talked about, including both of your LinkedIn, should anyone want to reach out to you guys as well. And we covered a lot there from both the leadership and the technical point of view. And I think that is incredibly valuable, getting you both on the same call there to show different sides of the project and how it was delivered. So thank you so much. I would urge everyone listening to check out those links in the show notes. But a big thank you to both of you for taking the time to sit down with me today

[00:29:01] and help bring all this to life from both a business leader and a technical perspective. Thanks again. Absolutely. Thank you, Neil. It's glad to be here. Have a good one. One of the things that I enjoyed about today's conversation with both of my guests is they cut through much of the noise that surrounds AI. Because yes, many discussions focus on models, tools, and the latest announcements. But they repeatedly brought this conversation right back to the fundamentals

[00:29:27] of understanding the problem, organizing the data, building trust, creating visibility, and just making sure that people can actually use technology to improve the way that they work. But maybe the biggest takeaway is that successful AI adoption starts with solving real problems, not chasing the shiny or the latest and greatest tech trends, and not deploying AI because, hey, that's what everyone else is doing.

[00:29:54] But identifying areas where people are struggling and then finding ways to help them work more effectively. But over to you, as AI becomes a bigger part of daily work, do you see it as a productivity tool, a digital colleague, or something entirely different? And what foundations is your organization putting in place to prepare for this next phase of AI adoption? As always, let me know. TechTalksNetwork.com. We can keep this conversation going.

[00:30:24] But that's it for today. Thanks for listening. Bye for now.