# Delivery Hero's Agentic Engineering Strategy

**Podcast:** HMZE
**Published:** 2026-10-15

## Transcript

Als wir eine Sache durch in December haben, wir haben gesagt, okay, wir nehmen 100 in Q1 und dann haben wir mit 1,800.
Und diese sind Merge PRs, so diese sind eigentliche Dinge, die in der Produktion gehen meistens.
In diesem Podcast, wir diskutieren die transformationalen Veränderungen in Software Engineering und Knowledge Work in generell.
Ich bin Sebastian Heidemeier zu Erten, CTO at Icosia.
Und ich bin André, CTPO at TrustedShops.
Great to have you back.
Today, wir sind in der Taktik-Engineering-at-Scale.
Exactly.
Our guest today is the SVP of Tech Foundations at Delivery Hero, and he's giving interesting insights into the transformation towards agentic engineering at the company.
So listen in.
It's going to be really, really interesting.
Welcome, Rodrigo.
We're super happy to have you.
You recently gave a very interesting interview for the German newspaper Capital.
Print Edition Capital.
And yeah, you described a lot how the age Delivery Hero is approaching agentic engineering.
And we thought it would be a great topic, obviously, for our little podcast.
So we're super excited to have you.
Please, before we jump into the main topic, introduce yourselves very briefly to our listeners.
Yeah, thanks, Sebastian.
I'm Rodrigue.
I'm currently SVP Tech Foundation at DeliverHero.
I've been in the tech scene since, let's say, since 1998.
I've been involved in more serious projects in the online space.
And I've been in deeding positions, so CTO or senior engineering manager positions, since around 2001.
So that's like a quarter century of that kind of job.
Mostly in the Berlin.
und der Scala-up-Szene mit Zolanda und Delivery Hero.
Das ist ein kurzer Rundown.
Ich bin jetzt auf Delivery Hero auf dem Fokus auf die Infrastruktur und Tool-Infrastruktur für alle die Engenheer und alle die Daten-Engineers, die Machine-Learning-Engineers und Allemes, what we call our everyday app.
Awesome.
Hence, you're exactly the right person for our podcast.
So we're, again, super excited to have you.
But before we jump into how Delivery Hero is approaching this, we have the small segment of the status quo where we ask our guests how they utilize Agentik in their workflows.
Do you have examples for us how you utilize agents in your day-to-day work?
Well, I mean, at the job, I use it mostly to prepare myself, right?
So this is about kind of prepping for the day, getting a summary of what's going on, getting some background context before I go into a meeting, for example.
It's also about kind of aggregating a lot of information so that I can make.
Ich denke, ich bin wahrscheinlich nicht der größte Creative Manager in terms of automating all of these tasks, aber ich versuche es bei, wo ist die Betriebe auf die Investment größte für mich?
Und dann starte mit dem.
Ja, das macht viel Sinn.
Und ich denke, wir sind alle das und es ist wirklich, ich würde sagen, ein pattern, das wir sehen mit jeder Gast heute.
Meeting prep, daily briefings, this is pretty much state-of-the-art right now.
Specifically also data aggregation, right?
Getting context for meetings for topics.
Also actually kind of storing context.
For example, what I'm also doing is I'm automatically generating weekly reviews of what I've been doing that week, right?
And I store that in a folder on G-Drive and then at the end of the year I have a pretty good overview.
of what has been going on that year.
And this, again, then also helps me provide better summaries, for example, also to my manager or group CTO to give him essentially a rundown of what I've been up to since we last spoke.
So this is also good.
The same can be done with my direct reports as well.
Due to the way that we have transcripts of our meetings, at least the ones that are taking place online, I have a pretty good knowledge base about what's happening there and I can draw from that as well.
So it's not just aggregating information, it's also kind of creating written context about things that are going on that can then be used later.
Ja, great.
Out of curiosity, is that a very individual setup or do you also share in your leadership team, I don't know, prompts and any other kind of automations?
I would say it's mostly personal.
Some people share.
their gems and their prompts for cloud or routines and so on.
But we don't have a really good, let's say, discovery around this.
Yeah, because I could imagine at your scale it would actually start to make sense.
There are some leaders in the organization with repetitive tasks.
So yeah, I was just curious to better understand how you approach it.
Absolutely a good observation.
It's also the same with skills.
Right now, we do have a place where people can publish their skill, but there's no curation.
There's nobody checking in on these skills and figuring out, is that even something we want to do?
Is that something that can be approved?
Maybe we have 20 times a similar skill.
So that is a bit of a governance problem, which we have, because all of this is pretty new, right?
And large companies are typically a bit slow in adapting to that and inventing or creating the necessary processes to have that sort of governance on top of it.
Yeah, maybe a final question on this one, specifically the sharing approach.
If you have a place already, is this a tool like?
In the Anthropik ecosystem?
Or is it just a GitHub repository?
It's GitHub-based.
And we have a website that basically pulls that information.
That's it.
But yeah, even, let's say, even ownership of this is not 100% clear.
So it's really a little bit of free-for-all at this point.
And something that we're working on to make that a little bit more controlled.
The same thing is happening when you talk about how apps are actually deployed and made available for others.
So, of course, you have things like artifacts and cloud, right?
But that might not meet your purpose all the time.
Then you have our own developer platform where people, engineers can deploy stuff in a, let's say, professional way.
But you also have a lot of users that...
kann man das developer-platform aber noch wollen, aber noch wollen, einen Website oder so.
Und das ist etwas, dass wir jetzt in der processen, eine Umgebung, wo sie sich safely verabschieden, was sie zu schaffen, und das zu anderen.
Das ist wirklich interessant.
Ja, danke.
Ich würde sagen, mit dem wir können, wir können wahrscheinlich conclude.
Vielen Dank.
Let our listeners know how you transformed the Agentic or the engineering organization of Delivery Hero.
Yeah, so maybe just to structure that a little bit, I think there are several dimensions that we could talk about.
One is how to enable engineers with Agentic tooling to be more productive and faster, right?
Second is the whole...
Autonomous Software Engineering Parts.
So the Software Factory or even Dark Factory is, I think, a label that many people use for that.
Unsert is the leveraging agents within consumer or business-facing products, right?
Which is also a big deal of what we're doing.
The consumer-facing, business-facing topics are not...
Das ist nicht über die Kunden, sondern über die meisten Projekte.
mit dem Essen auf die verschiedenen Plattformen.
Wir haben viele Vendors, viele Restaurants und ein Real-Sales-Agentes, das ist für sie, um sie zu helfen, ist nicht einfach.
In den letzten Jahren, was wir mehr auf die Art ofiteiten für sehr hohe Profile.
While the others didn't really get that level of support, now with agents, we can actually provide that support to everyone.
And that's, for them, a pretty amazing thing.
It goes so far to, for example, identify or make proposals in terms of the menu that they have, in terms of the pricing, in terms of campaigns that they should do, and so on.
So it's a neat tool.
Customer services, I think, nothing.
Es ist ein sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr Ja, wir glauben das ist wahrscheinlich wegen der freshness von dieser Technologie.
Ja, sorry, für mich zu verstehen.
So, die Kases können wahrscheinlich wiederum werden können oder mit fewerer Steps, aber NPS ist es höher?
Ist das wie das Ihr Interpret?
Ja, kind of.
Wir sind nicht mit NPS, aber es ist eine andere Metrik.
There is a visible difference between the agentic interactions and the human interactions in terms of how people rate that interaction, right?
Despite having better outcomes.
That is interesting.
So we're looking into that and trying to figure out what's going on here.
In terms of agentic tooling for engineers, In the beginning, we were experimenting wildly.
DeliverHero ist eine sehr decentralizede Gruppe.
Wir haben viele große subsidiaries.
Die subsidiaries haben ihre eigenen Tech Teams, Tech Platforms und so weiter, ihre eigenen CTOs.
Und natürlich, sie wollten sie versuchen, sie zu versuchen, auf ihre eigene.
In der Beginn, wir haben das als Vorteil, indem wir das anwichtigte, mit vielen Piloten mit vielen ...
We had different big players like Cursor.
We had Windsurf before they got bought by Google and I think Devin bought the rest.
I'm not sure.
Don't ask me.
We also had Claude, of course.
We had Gemini Code Assist, which we used in Berlin since mid-24, roughly.
Und ja, wir haben versucht, die Qualität zu finden, wie sie benutzen, und wir haben die Adoption gefunden und haben, die wir in den Zusammenhang mit den Zusatzern gefunden haben.
Wir haben immer diese Art, die relativ klein, Power User Group gesehen haben.
Es war immer rund 10-20% der Leute.
While the rest didn't really buzzer.
This was early in the phase where the models were also not yet that strong.
And at the beginning of this year, we decided to move towards a central stack, at least for the central teams here in Berlin, which is already a lot of people.
We're talking about 1,500 engineers here.
So we wanted to do that mostly because we saw that If everybody's trying out things, we don't have any level of governance on that.
So this is really about things like, of course, compliance and security play a big role here, but also things like being able to measure what they're doing with it, right?
Because if you have like a dozen different providers that send you a dozen different...
Then it becomes really hard to figure out, okay, how much did they use it?
How much code was actually generated with it?
And so on.
So this became a little bit of an issue.
Same with cost control, right?
And in general, with figuring out what kind of ROI do we have with that?
So we wanted to centralize that.
We want to have some sort of technological ownership.
On that topic.
And then we went with one vendor to roll that out to at least all the central teams.
Right.
And opt in with some of the subsidiaries who also chose to go that route.
And that's what we've been doing since a couple of months.
And pushing for adoption, pushing for upskilling.
Of people to use these tools more and at the same time, of course, also trying to control the costs, which obviously can explode pretty quickly when you don't have an eye on that.
At your scale, I could imagine this is a huge topic.
Are you allowed to disclose which...
Is it something very special or is it straightforward as you would expect?
Maybe OpenAI?
Relatively straightforward.
So in Central, we're currently focusing on Cloud.
In the group, we have other players as well, such as Gemini, that's our South American company.
Und einige andere Unternehmen haben auch noch einen Kontrakt mit anderen Vendors.
Aber die Hauptsache ist Cloud und das ist das wir beherrschte, weil es auch die Software verbunden ist, mit einem non-tech Produkt, mit Co-Work, das man kann.
Wir wollten sie ein Tool, und das viele Leute in Nontech sind sehr excited.
Es ist immer noch, ehrlich gesagt, von der Kost perspective, es ist nur ein Fraction.
Absolutely.
So we are running the same strategy, so I know, but probably in different scales.
So it would be also maybe as a follow-up episode to better understand how you do cost control at that scale, because your subscription probably does not fit into a limited model anymore.
So you pay by the token, same as on our side.
So that also creates some new challenges, so to say.
Ja, das ist wahr.
Wir sind nicht auf das 150-Leute-Team-Plan.
Es kann sich nicht so machen.
Wenn du das 150-Leute-Türkst, würde ich auch benutzen.
Aber in unserer scale, die Idee von juggling User Accounts über mehrere Team Plans wäre ein bisschen über die Tau.
We manage that through the Cloud API.
We set limits.
We build tooling on top of Cloud because Cloud functionality was not enough for our needs yet.
They're working on making that better.
We can per organizational unit, we can define limits.
We can define limits on an individual basis and we can track overall spending.
So we have that.
So what under control engineers can tell us what they use it for.
Right.
So if somebody is like requesting another $200, they need to provide some sort of context about what they're working on to to understand is that worthwhile is that maybe not worthwhile.
Impressive.
Yeah.
So so this this was basically the starting point.
Lots of experimentation in the different orgs.
Right.
And then starting to.
bring this into one structure for governance purposes.
And this is basically what you then rolled out in Berlin with one provider and other providers in other companies.
Exactly.
So that setup also allows us to keep track on other vendors and see how their products develop.
Das ist ein sehr, sehr schnelles, sehr schnelles, und du willst auf dem Weg.
Der erste Punkt, was die Autonomous Software Delivery.
Das ist etwas, was wir mit dem Jahrhundert.
when models were still not that strong.
So I remember myself playing around with Firebase Studio at the time, right?
And it was nice to see that it could create something out of a prompt and that something kind of worked, right?
You could build dynamic web applications with that, even with interesting business logic behind it and so on.
But when you worked for longer on the same code base, it really deteriorated.
So, at that point, it was clear that this is not yet ready for actual production cases.
But it was also clear that if you look at how fast models got better also in other areas, let's say in image generation or video generation, I think personally, I felt I was very amazed about the jumps that video generation did.
I was also following a lot on the image generation since a couple of years already, mid-journey mostly.
was was clear coding will improve soon and really with step changes right not with like small improvements here and there but I was expecting that this will become good enough for larger production ready software projects and that's why we wanted to build a harness around it already so that when the models become dass wir etwas, dass wir das so, dass wir mit dem, dass wir mit dem, so wir haben, ein paar, so drei, wirklich, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr Es ist integriert mit unseren Environment, so es geht um CI-Tests und geht es mit den Feedback von CI.
Es integriert mit GitHub und geht es mit Gira und kann man mit dem Kommentar mit dem.
Es ist im Bedarf, was wir als unsere Entwicklung bereits als development.
At that point, the strong models hit.
This was, I think, around November, December last year.
And that was really good timing because when we launched this internally, first with test users in January, we already hit our initial Q1 target during that kind of under-the-radar launch.
Und dann wir öffnen, wir öffnen es für alle zu nutzen.
Und in Q1, wir hatten wir unsere Targets several times.
In der Ende, wir haben 18x den Original Target in Q1, weil es wirklich skyrocketet in terms of Usage.
So es war Usage Targets oder PR Targets?
PR Targets.
So vielleicht waren wir auch sehr conservative.
As we got one thing through in December, we said, okay, let's take 100 in Q1, and we ended up with 1,800.
And these are merged PRs, right?
So these are actual things that go into production most of the time.
We were also very impressed by the merge rate in the beginning, so this was quite good.
Ich weiß nicht, was wir in January endet mit.
Aber in der Anfang, wir waren bereits über 60 Prozent.
Als ein Startpunkt, das ist ziemlich stark.
Und jetzt, die Merge Rate ist, ich glaube, in September war es 83 Prozent von all den PRs, die sind, die Merge sind.
Most of them, also without any additional change or command by an engineer.
So most of them are one-shots, which is also something that we're now trying to improve on.
Because if our goal is next year to have an end-to-end software factory working, then of course the one-shot rate is extremely important.
Since then, we've increased the team size, we've worked heavily on that, we've added features to gain more adoption, to improve the quality.
And that's what we're still doing.
And now I think we're kind of at the same level as some of the other bigger tech players who've built similar things like Spotify or Stripe.
Uber, auch in diesem Bereich, hat sehr starkes Zahlen.
Wir sind in einem guten Platz.
Ich bin ein Belieber, dass wir es noch mehr in den nächsten Jahren können.
Jira Tickets, and then at some point the PR merge, the manual PR merge?
Are these the interactions?
Kind of.
We have more interaction points, but the Jira Ticket was the original, the OG of interaction points.
You wrote a ticket, and then you just assigned it to the HeroGen user.
You still had to put in, and that's still the case, unfortunately, the repository that you wanted to work on.
Das war es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, und dann hat es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, ein Beispiel, ein Council of Review Agents, das ist, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, wenn es, Adds to the Jyra ticket, hey, I'm done, this is what I've done, changes the status, and then the engineer can take a look and can comment on the ticket.
If they comment on the ticket, the Herogen agent picks that up, makes necessary changes, and in the end, we still have the human approval, right?
That is something that is right now queuing up a little bit.
Because you can imagine that with all these additional pull requests that need to be reviewed by someone, people will become a bit overwhelmed.
So you see that the review time goes up, right?
Overall, and what we're now planning to address that is to start with classification of PRs to see is that dangerous, is that not dangerous?
And if it's not dangerous, we can just auto-approach, right?
So that's the direction we're taking.
Ich denke, das auch für nicht-agenten PRs.
Was ich meine, wenn ein Software Engineer creates a PR, ist es jetzt nicht mehr, aber wenn es ein PR ist, kann man auch nicht mehr, wenn es ein PR ist, kann man auch nicht mehr, wenn es ein PR ist.
Aber wenn es ein PR ist, kann man auch nicht mehr, wenn man das nicht mehr, wenn man das nicht mehr, kann man das nicht mehr.
Aber die Punkt ist, dass es sich nicht mehr, wenn man das nicht mehr, Auto-approval, we will also need to turn up our DevOps practices to 11.
So we need to have safety nets in place, like cannery rollouts with automated rollback, that even if things go wrong through an auto-approval, limit the blast radius of what happens and also feedback into the agent itself to say, hey, this is what we saw when rolling it out.
Fix that.
And this is something that becomes more and more clear is that a lot of the practices on how we get software to production in a safe and fast way have been there for quite a while.
So we had these DevOps practices for over a decade.
And any company you look into has some sort of processes established that Aber es gibt nur sehr, sehr, sehr viele Unternehmen, die alle 10-malen waren, die wirklich alles haben.
Und haben wir auch immer wieder, haben wir auch immer wieder, haben wir auch immer wieder, haben wir auch immer wieder, haben wir auch immer wieder, haben wir auch immer wieder.
Aber mit Agents, Sie wollen das wirklich in place, weil wir die Speed von The code production that you can see, you cannot afford to have either to rely fully on software engineers kind of verifying everything or to rely on software engineers dealing with incidents in production at that scale.
It's just not a viable approach.
For sure.
Yeah, thanks.
That actually is really impressive what you describe here because I feel like, yeah.
Es ist nicht viele Unternehmen, die sind schon weit entfernt, auf die Automation.
Specifically, die Route zu fully automatisch werden, und dann jetzt die Reviews zu erreichen.
Eine Frage ist, ist das eine-size-fits-all, das ist eine Harness, die du kannst, wie eine Repo geben?
Like it can handle any type of service because the services can be totally different, right?
It could be something user-facing, it could be something that pretty much just handles data or it could be a transaction system.
Can it handle everything or are there specializations?
So how did you structure this?
It's a generic thing.
So the harness stays the same, the model, the primary coding model stays the same, the reaver model stays the same, right?
But what we're looking at is to create a little bit more of a long-term memory in the future where the model understands what it has done with the codebase and keeps that information for next time.
So this way it might get better over time on a particular codebase.
But we don't have a specialized agent for, I don't know, iOS apps or a specialized agent for something else.
That's not...
currently, what we're doing.
And I'm also not sure if that's the future.
Might be.
I mean, honestly, if training on a very specific problem space would be available, I think you could achieve better results with that kind of specialization, but it also requires a lot of effort.
So then maybe...
So basically the agent is tagged in the JIRA ticket, right?
It then gets the repo and then the repo probably contains some contextual information, right?
So like agents MD or cloud MD or whatever, context MD.
So the contextual information and then the agent will just based on this given contextual information within the repo and probably skills library, MCP libraries will then Ja, das ist das richtig.
Mit den Repos selbst, haben wir mehr Kontexten als andere.
Wir haben auch die Repos, die nicht mehr Kontexten haben, oder CloudMD-File haben, und nicht mehr Kontexten haben, die sich nicht mehr Kontexten haben.
depending on how much context the repo has.
The biggest problem we have right now is that the repo does usually not have context about its dependencies, so it doesn't know how the full API of some other service looks like that they're calling necessarily.
So maybe, of course, you can see the function call, but you don't have the full picture.
And this is, especially if you're talking about, let's say, APIs that the repo does not use right now, but that would be needed for the feature that you want to implement, then this information is completely missing.
And that's something we're tackling now to create that kind of context hub where the agent will be able to understand a lot about the architecture, about the dependencies in this microservice landscape.
und dann be able to make decisions on what it needs to do.
I agree with Sebastian.
Probably one of the most advanced agentic workflows we have seen or we have heard about.
So very impressive.
It's not publicly available, right?
And there are no plans asking for a friend?
It's not publicly available.
Aber wir haben schon über das Thema gesprochen.
Okay, so dann sollte man sich an Augen auf den Publicen repos von Delivery Hero geben.
Das ist ja so.
Ich habe viele Fragen.
Unfortunately, wir sind nehrt der Ende der Episode.
So ich würde sagen, wir haben die Hauptsache mit dem Thema.
und gehen zu den zwei kurzenen Segments, die Ende des Episodes sind, der erste ist die so-called Reality Check, wo wir immer fragen, was wir uns für die F**k-Moment oder wow-Moment sie haben, die sie mit LLM oder Agentic Systems haben.
Do Sie haben etwas in dieser Kategorie zu share mit unseren Listenern?
Ja, aber ich will nicht nennen any Model oder Renderer, weil wir haben mit denen, ich nicht.
Ich habe eine Multimodal-Model-Model-Insträger auf nicht zu verstehen, dass sie nicht mehr able zu verstehen, oder Videos zu verstehen.
Es war definitiv Multimodal, aber ich weiß nicht warum, es war nicht so, dass es das Kapazität hat.
Das war eine sehr weirde Sache.
Und manchmal, wenn es ein paar Prompts gibt, es eigentlich...
Und was able to do it.
So, these are situations that are a little bit strange.
And in this case, this happened really in the very early stages of multimodal models.
So, we're talking, when was that?
I think that was actually, could have been last year.
So, not very recently, basically.
It's not very long ago.
I see, yeah.
And is there anything that...
excites you specifically right now?
So something where you say, okay, this is the next big thing?
Yeah, I mean, I think that agents that can act on your behalf are an awesome idea to some extent, but I also see a lot of risks in that.
So I was not one of the people who kind of bought a Mac Mini and put OpenClaw on it, right?
But I think it's...
Es ist immer noch ein sehr, sehr interessantes Richtung.
Um zu haben eine Person-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Astin-Ast Also risk around privacy here, risk around identity theft in the end.
So I'm not 100% sure if I would do that.
Currently, I'm also looking at things that you want to do that deal with your private life, such as you want to do your text statement, right?
And you want to do that with AI.
If you do it with a subscription, then your data might end up...
in the training mass.
This can be quite confidential, in fact.
What I'm looking at here is more like, I hope that with the new hardware that's coming out, that we'll be able to run strong models locally without having that kind of risk.
And with agents, I think running them locally without having to call any external subscription.
Das API ist auch ein sehr, was es mit den Risiken zu verändern.
Ich möchte zurückkehren die Hauptsache, aber haben Sie auch noch über die Anführung des Anführungsgerichts für Ihr HeroGen?
Für HeroGen würde das nicht wirklich möglich sein.
Quality is still a very important part.
And usually when you switch to local, you either need to invest massively into hardware, right?
To run any model that comes close to what the Frontier models are doing.
And yeah, no, we haven't done that yet.
I know that one of our subsidiaries has tried that out.
So they bought a bigger machine from AMD to do that.
It wasn't worthwhile for them.
Ich denke, diese Dinge ändern.
Als die Hardware wird, die die Mehrheit wird, wenn die Mehrheit wird, dann wird das wiedersehen.
Und dann wird das wiedersehen, dass die Leute wiederumschte, wenn die Cloud starten und die Leute starten zu移ern.
Ich denke, die Dynamiken sind vielleicht ein bisschen anders.
Third-Party, where you can offload your hardware-place to, or workload to, and it deals with that.
But if that is too expensive, then you will consider doing it on-premise again, right?
And this kind of tension between too expensive to run it with a vendor and the hassle of doing it yourself, this needs to balance out in some way.
Given the current situation with hardware, with also cheap models coming out of China and cheap models in the open-weights space, I think there will be pressure on the bigger players on the Frontier Labs to keep prices somewhat acceptable, which in turn will lead to people not going the on-premise route because on-premise always means At least if you do it in a company, you need to have people who manage the hardware cycle, who maintain that thing.
And this is, at scale, this might be worth it.
Yeah, this is actually the reason why I was asking.
You probably have the scale, but I also fully understand the feedback on quality, the feedback on actually also the nice...
Interaction zwischen der Abilanzierung und der Pressure, die es auf Frontier-Modeln zu halten, um die Kosten zu einem gewissenen Wert zu halten.
Ich denke, dass es vielleicht genug ist, um das sweet spot zu bleiben.
Ja, ich sehe es, dass OpenAI und Entropic-Prizen-Prizen-Down-Recentlich mit den neuen Modeln.
Es geht in das Richtung.
In unserem Fall, wenn wir das machen, ich denke...
We probably would have to hire a department of system engineers to keep that up and running.
Or alternatively, you can also use the cloud, right?
So you can host that on Google or on AWS.
And then what you have is basically you pay for a very expensive instance that is not used 24-7 because your engineers are also sometimes out of office.
You would need to make that calculation if that's actually worth it, right?
What's more expensive?
This with the waste it gives you or paying by usage with a vendor like Entropic or OpenAI?
Yeah, and I think you're pointing at exactly the right or important points, right?
It's the price wars, basically.
Ja, das ist ein bisschen mehr.
They are ahead and that's a race.
They need to stay ahead in order to stay relevant on the inference level.
And on the other hand, they are also trying to integrate more deeply with their, like the OpenAI dots very recently.
They tried different approaches, right?
Cloud, co-work and whatnot.
So I think it's very interesting to see this, but I'm fully with you that right now for most companies, probably like if...
They can utilize subscriptions, then it's anyway heavily subsidized and it's a no-brainer basically.
If not, then still it's right now the price point and also the quality level that you can get and the ease of use is worth a lot.
So it's hard to make a case for going entirely on-prem.
Yeah, I would only do it if privacy or sovereignty would be really key.
Dann ist es natürlich ein bisschen, aber wenn nicht, dann haben wir diese hohe Upfront-Cost für die Hardware, die du hast, die du hast, die Personal und so weiter.
Das ist einfach ein bisschen viel hassle.
Und du musst es auch nicht so gut.
Das ist auch nicht so easy.
Dann haben wir eine letzte Segment, die ist Prediction.
Prediction, yeah.
So, I mean, as we're working on this end-to-end software factory at DeliverHero, I think we're, as I said, we know others are also doing that.
We know there are several vendors that are providing tooling for that.
I think end of next year, we'll see that this works end-to-end, right?
So that this is really a ticket that goes to production in a safe way.
is also check for anomalies.
We'll back, if things go wrong, we'll see agents that can handle a certain percentage of operational incidents automatically.
And we actually need that.
If we can't do that, we're blocked because incidents typically scale with the number of deployments that you do if the change-failure rate is at a similar level.
Handling of these incidents is still primarily done by software engineers, then we have a huge bottleneck.
And a bottleneck that's not about just capacity, but it's really about resilience.
Yeah, or actually surviving in terms of our business.
Because if you can't handle incidents anymore, it's probably game over for most.
Okay, noted.
End of next year, we need to reach out and ask you whether your prediction became true or not.
Okay, I'll take that challenge.
All right, thanks a lot, Georgik.
It was great, very insightful.
And yes, thanks for being our guest.
Thanks a lot for being here.
The Beyond Vibe Coding Podcast is a project by Sebastian Heidemar, Zerpen, and André Neubauer.
Partnering with ImpalaSearch.
The content is created by us and our guests.
Join the discussion on LinkedIn or visit our website where we publish all episodes.
For questions and inquiries, feel free to reach out via LinkedIn.
Thank you for your time and see you in the next episode.