# AI-Native Engineering: Platforms, Agentic Workflows, and System Architecture

**Podcast:** HMZE
**Published:** 2026-07-09

## Transcript

Ich habe meine Betten, dass wir in bestimmten Teams können, vielleicht nicht zu all, am besten zu all.
The go-to tech and executive search agency in Germany.
In this podcast, we explore the transformational change in software engineering and knowledge work in general.
I'm Sebastian Heide, Meier zu Erbem, CTO at North.io.
And I'm André Neubauer, CTPO at Trusted Shops.
Great to have you back.
This time it's Palo again.
Yes.
And while last time we talked to Shabba about their agentic products, this time we are talking about how they built these.
So basically, how the company that builds agents engineers Agentic.
Welcome to the podcast Italo.
We are super happy to have you.
And as usual, we ask our guests to introduce themselves to our listeners.
So would ask you the same.
Please introduce yourself.
Absolutely.
Thank you.
And thank you for having me.
It's really, really a pleasure to be here.
So I'm Italo.
I am currently working as Senior Director of Engineering at Parloa.
Ich habe mit dem Unternehmen nicht für lange, aber über 10 Monate, aber ich kann Ihnen sagen, es ist viel mehr als das, weil wir so in eine fast-paced environment.
Previously, ich war in viele, viele Unternehmen hier in Berlin.
Wenn ich hier hier, um 12 Jahre alt, ich begann die HalloFresh, als der Herr von Engineering.
Und dann, ich habe dann auf N26, Urban Sports Club, Babbel.
So you know it.
And then eventually I landed at Parloa in a very different challenge.
What was common across those companies, I always worked in Platform.
So that's the area that I love and that I have a lot of experience on.
So always trying to think about Platform as a product rather than as a cost center in the organization.
And then I built teams and organizations around this over the past few years.
Originally, I'm from Brazil.
Back in Brazil, I was working for the Brazilian government for a while in the old days of Java and C Sharp.
And then eventually I moved on more to HelloFresh here in Germany.
So yeah, it's a little bit about me in a nutshell.
Awesome.
Thank you.
Thanks a lot.
Yeah, platform is also something that is near and dear to my heart.
Absolutely.
So the best thing is to get into the product.
basically, and not see it just as a cost center.
However, it's usually hard because the standard mode is a little bit the one of a cost center, right?
But yeah.
Yeah, it's a mindset shift overall, right?
So we always think as a platform, not as a leverage for the organization.
We started as like, it's something we need to have, right?
Like infrastructure, reliability, security, like those things are given.
But once you...
Flip the coin and think about them as Potentially like revenue Revenue generators You also change how you think Organically in the organization and how you build the teams around So I really like to Always think about Platform as opportunity For scaling the organization And not as a cost Dragging mechanism That's a great way To phrase it and also specifically Und die Hiring 4, these platform teams, as you mentioned, usually in my experience, you have more the type of engineers that are interested in juicy challenges as opposed to being super product minded, right?
So you need to have like both in a platform if you want to apply this mindset, right?
So that's super interesting.
And maybe we can talk about this later.
I'm pretty sure that it will come up again.
As usual, we always start with the status quo.
So a little bit about how you are currently working, what the tools are, the workflows, if it's changing a lot, if you're experimenting a lot, or if you think you have a stable state, basically.
Yeah, please let us know.
Yeah, absolutely.
I mean, I think my work style has changed dramatically, for sure.
Especially in the last, I would say, 18 months.
mit den neuen Modeln, die kommen aus, die von AI-assistenten kind von Wissen zu arbeiten, um mehr agenten workflows zu arbeiten.
Particularly, ich meine, heute ist nicht mehr Hands-on mehr in Coding, aber ich mache es auf mein eigenes Zeit.
Ich bin ein großer Lover, specifically von Home Labbing.
So I love to, you know, work with homelabbing, home automation and everything around this.
So I practice and put it in practice on my whole homelab.
Like, how can I make it better?
How can I automate more?
How can I, you know, with the lack of time that I have now with a little girl to take care of also, how can I make sure that in the little time I have invested in my homelab, I can get the biggest leverage out of it?
Und für das, ich arbeite ein viel.
CloudCode war ein Game-Changer für mich, Tremendlich, besonders die Automated Agents part.
In der Sandbox mode, ich tried alles.
Ich tried OpenClaw, Hermes und so an, all die verschiedenen Agents.
Sie sind cool, aber die Leverage von CloudCode war so viel größer, dass ich nicht nur auf mein Day-to-Day work use.
But also in my free time, whenever I want to try something out or prototype, you know, it opens doors in that regard.
And I think specifically on agentic workflows, what really, really changed the way I work is that I don't like to use AI to generate documentation and, you know, talk as me.
specifically, because I think writing helps me think better.
So I still do the writing myself.
And this keeps me concise, which is, you know, something very, very important for me.
I like to avoid the AI slop as much as I can.
But I do use AI as a rubber duck kind of idea, right?
So I discuss with it, like, hey, what do you think about this?
Where are the flaws in my potential thinking or design?
Challenge me back, right?
So I develop a few skills for myself on...
Ich habe mich besser als ich mich zu erreichen.
Und das war wirklich interessant.
Especially wenn ich es mit Whisperer benutze, dann ist es wirklich einfach, weil es einfach nur zu sprechen.
Ich liebe es zu sprechen.
Wenn nicht ein Rubber Duck, dann zu Claude, zu sagen.
Ja, das ist super nice.
Super nice way zu puten.
Es ist zu nicht verlieren die Abiligung zu denken straight und auch zu wirklich strukturieren.
It reminds me of how I work.
So I'm very honestly, I'm usually starting with some notes and then have the AI flash out a document.
However, then I edit the document very heavily.
So because I always feel like it's not my style, it's not how I would put it.
So I think you're doing it even more straight than me.
But I also like to not just use what the AI produces, but edit it.
sehr viel, das dann auch macht mich, weil das dann auch die AI, die sich in die Frage, die ich in die Frage, oder anwesst, was ich nicht wirklich gezwungen, und es gibt immer diese Fragen in die ich würde, und es gibt immer diese Fragen in die ich würde.
Und so ich habe das sehr klar, weil ich das nicht ausfusstehe, es wirklich hilft.
Ja, es ist ein Back- und-Fortes und ich denke, das ist so gut.
Es gibt vielleicht auch die Sachen, die ich nicht gedacht habe, und dann ist es, ich denke, ich muss mich über das und ich muss das, ich muss das, ich muss das, ich muss das, ich muss das.
Es hilft mir zu strukturieren, aber ich liebe es zu schreiben, aber ich liebe es selbst, auch mit einem Notebook.
Wenn ich kann, ich immer ein Notebook mit mir, so ich kann eigentlich die Note-Taking selbst, weil die Art auch macht mich besser.
Aber ich benutze AI ein bisschen, weil ich nicht ein Englisch-native-native-speaker habe.
Also, es hilft mir mit Grammar oder mit Cohesion in meinem Text, wenn es nicht perfekt ist.
Aber aside von dem, ich versuche es sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr.
Ist es ein bestimmtes Framework you're using?
As in in my day-to-day work?
Ja, in your day-to-day work.
There's no specific framework.
I like to use a lot the different types of when I'm coding something, for instance.
Let's think about spec-driven development for a second.
I started with GSDD, which was pretty solid.
And then I move into OpenSpec.
OpenSpec for me is the one that I currently use the most on, hey, here's an idea for my home lab or here's an idea for a prototype at Parloa.
Spec it out.
Implement something.
Let's see how it gets there.
But the harness I created around it, that's really what gets the production code up to the speed, right?
And to me, my home lab is my production in my free time.
For Paraloa, obviously, we have much more production rules to put in place and the harness around it.
But the principles are the same.
Spec it out, research, implement, validate, and deploy.
So it's usually I go through these steps.
No matter if it's a Paraloa or also in my private projects, it's usually the same, right?
So no specific framework, but spec-driven development gets me close to a structured thinking.
And for your management work, the reason why I'm asking is like, I was wondering if there is actually a good framework or if there's a space where...
Ja, like getting shit done for managers, right?
So a framework, well, I think it could help you there as well, right?
Absolutely.
So it was interesting to better understand how you use that or if you have some skills.
Got it.
I mean, honestly, management is interesting because you're putting in a fair question.
Is there any kind of framework managers could use to...
their productivity or to help them think differently.
The thing, this is my personal take, I think management is so unique in terms of like you're dealing with people and because you're dealing with people, not every single individual will fit the framework, right?
So you have to adapt.
That's the servant kind of leadership also, right?
But there are certain level of administrative work that we always have to do that can be automated.
Und für das, für sicher, ich habe eine Skill, für instance, für Helping Me on Performance Reviews.
So wir haben eine sehr interessante Skill, das geht in Leapsum, hilft mir zu bekommen, die Leute, all die Dinge, so ich nicht mehr zu machen, so ich nicht mehr zu machen, und dann Struktur Feedback properly, so ich kann das Feedback in eine concise Art und Weise geben.
Und das ist ein Spiel wir auch an Paraloa für alle Managers, dass sie aus der Box können.
Es gibt ein paar MCPs hier und da, wie Leapsum, es gibt Feedback von irgendwelchen anderen Tools und links zu unseren Career Framework Specs, speziell, auf die Ereis wir wollen, die Individuals auf.
So das ist ein Teil von uns, was wir callen unsere Kitchen, die ich noch mehr über darüber sprechen.
Aber basically, es ist ein Teil von uns, was wir auch für Managers.
We also have one that I use daily, which is hiring, because we're hiring a lot.
And I don't like to offload the decision of hiring for AI, right?
I think that has to be a human based on our experience for multiple years.
But AI can definitely help, you know, dig into that specific candidate.
especially in their experience and CV, and kind of direct the question book you already have and say like, hey, maybe you want to ask these questions because given the experience of this candidate, makes sense for us to probe in this area for this stage of the interview.
And that is super helpful when selecting the right questions from our question log and just bring it up.
So we use that a lot, constantly.
Yeah.
Thank you.
Honestly, it rhymes with how I'm thinking about this.
We also have been talking to several people that have partially automated certain elements of their day-to-day work, like getting a morning briefing from different conversations that have been going on.
Here's the stuff that's important for you today.
I feel like the more...
The more responsibility you have, the more diverse are the topics that you have and the more ad hoc the topics feel like, which means that the standard way of automation where you flesh out the process, right?
And then you look what you can automate and how you can automate it.
That's a bit harder if you have very different diversity of tasks.
Und specifically, da ist es, wo es kommt zurück zu den generalen, wie management, die Themen, die managentur, wie managentur, wie managentur, hirung, etc., dass man automatisch kann, weil diese kommen wieder über und über wieder.
So, ich habe ja schon mal gemacht, habe ich mir standarde Rolle, die ich meine standarde Rolle, die ich standarde, die ich für Assessments habe, und ich habe eine standarde Format für wie ich dann...
all the information and put it in written for someone so that the person can then use it.
And this is also for me pretty easy now with Cloud Code.
That's what I'm doing it with to generate a proper documentation and also assess it from different angles.
I ask Cloud Code to ask me questions and also assess the way I'm doing the writing there.
Yeah, that's very good.
Especially on the The amount of information we have to access, the higher you are in the organization, the more areas you probably take care of, which means more heterogeneous it is.
Curating what you need to do on the day, super useful.
That is something that we also use here.
We have another skill for curation, content curation on a daily basis.
Like, hey, get it from Slack, from email, from all the different sources.
Tell me, what is the most important thing I should do today?
And where should I start?
It's pretty useful for that.
Yes, cool.
Thanks a lot.
I guess we have a decent overview of your tech stack and your workflows, right?
And I guess it's time for the meat, which means the...
So, today we obviously are super interested in learning how the company that builds agents actually does agentic engineering.
And yeah, so please let us know how you work, what kind of standard practices you have, etc.
Absolutely.
So, that's the fun part and that's why I chose also to work at Parloa.
Wir sagen, dass wir AI zu bauen, so das ist die Hauptsache.
Wir als Parlo, natürlich, unser Hauptprodukt ist ein Agenten Platform, das ist das wir bauen.
Aber gleichzeitig, wir als Organisationen als AI-native sind.
Und was das das tatsächlich bedeutet?
Wir müssen das ein bisschen über das ein bisschen.
Aber AI-native für uns bedeutet also, dass alles in Parlo started, was auf Engineering.
So we're like, okay, the engineers had the first tryouts with, let's say, with AI, with AI-assisted coding.
Think of the days of Copilot.
We started all the way back there.
And very fast we evolved as a department and then eventually as an organization, right?
So everything started on Copilot, then eventually Cursor.
Some people started migrating to Cursor, playing with AI-assisted coding.
So just maybe started from autocompleting better to eventually actually doing a whole file for themselves and eventually the whole system.
The true differentiator for Parloa in the AI world was, of course, when Cloud Code came out around Feb last year or something, Parloa jumped right into it because we had some very exciting engineers.
They wanted to try it out.
And by being an AI, So that was the thinking for a lot of engineers.
So a few of the engineers, they start going into this Cloud Code area.
And bear in mind, when Cloud Code was out there, there was no skill, right?
So people were still using the rule files and not even agents MED.
It was Cloud MD only.
Eventually standards start coming up.
And there was one specific engineer in our organization that once skills were out, they created what we call the kitchen.
So we started with the kitchen and I'll get to why the kitchen eventually.
But we started with what we call the kitchen.
And the kitchen is nothing but a bunch of skills together.
It's the harness, right?
So it started simple.
Helped me with my TypeScript and Python code.
And that's it.
So help me a little bit there.
And eventually started evolving into more and more and more skills.
So think about...
eigentlich, dass wir unsere SRE-principationen, die sich in der Sicherheit auf die Sicherheit auf die andere nicht-funktionale areas, dass wir als engineers, wir als Engenheer brauchen, wir starten zu den Kuchen.
Und, you know, eine Sache wir realized ist, dass wir alle diese Skills haben, und sie sind in eine nice Repl in GitHub, und vielleicht ein paar andere Engenheer wissen, aber es ist nicht systematisch.
People sind nicht systematisch.
Because there was no investment from our side into pushing this out into the engineering organization.
At some point, I remember we have something called Accelerator Week, which is a week where Parloa invests every six months, where we invest product and engineering to stop for a week to innovate.
Think about how can we innovate in our product.
It's not really a hackathon, but it's really a dedicated...
für uns zu denken, wie wir besser verbessern.
Und in das Woche, specifically, da war ein Team, der sagte, ich will, ich will, ich will, ich will, ich will, ich will, ich will, ich will, ich will, ich will, ich will, ein paar Worte, ein paar Worte, weil es war, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein paar Worte, ein Without us touching the code, can we do it?
So they pair a little bit and throughout the week, in the end, they did deliver a very solid service, which, you know, had equal parity in terms of features with the previous one.
All the non-deterministic checks from SonarCube, so meaning our NFRs were covered for.
And they deployed in production and released already to a certain percentage of our customers, right?
To test out so blast radius wouldn't be much of a problem.
So this was a proof at that moment that, okay, this kitchen thing seems to be actually more solid than what we initially thought.
And then we created something called Show Me How You Cook.
So the Show Me How You Cook is basically all engineers and product people and design, they come together.
It's voluntary, so they can just show up and show what you've done with AI in the kitchen.
So if you do show something there, first thing you're going to earn is actually a Chef Hat Parloa branded, obviously, because the kitchen, right?
So we gamify a little bit.
So if you go up there and you show something cool, you're going to earn this very nice Chef Hat.
Now, if you develop something really unique that has customer impact, you earn a nice MasterChef apron.
So now you are...
One of the advocates for the kitchen and for AI in Parloa.
And we start developing this more and more and more.
People start going to this show me how you cook kind of event.
And more people started contributing to the kitchen.
More skills.
Now that's when managers start contributing their skills.
Like we just discussed the hiring skills and so on.
Eventually we had...
We had skills for security and security threat modeling.
So things start growing a lot, but we start realizing that, okay, 95% of our code base was actually being produced now by our kitchen and its harness, but not necessarily us pushing code anymore ourselves.
And this is a double-edged sword, which we can also deep dive here in a second.
But basically that's the journey we went through until up.
two months ago.
And then we jumped into the agentic world, which I will talk more about later.
But that's kind of the journey until that point, right?
And then people got on board into this whole kitchen thing, which was just a catalyst for us to spread AI across engineering specifically, and then product right after, which was quite interesting.
Super interesting.
So it's pretty much the...
The start of the transition, right?
Up to a point where 95% of code is written this way.
That's pretty impressive.
And you mentioned double-edged sword.
Can you detail this a little bit?
Yeah.
So think for a bit, right?
Like what is the thing that we're optimizing the most in the software development lifecycle with AI today?
It's the code writing part, right?
But if you really think about it, code writing was never the lowest part of software development lifecycle, even before AI.
Das war never the really difficult part to solve.
Everything around it was much more difficult.
So how do you spec things out?
How do you validate?
How do you test?
How do you roll it out to production?
How do you make it resilient?
How do you make it reliable?
So those were the difficult parts of software development.
And that's usually where delays happen, right?
Like the non-functional start appearing, you didn't account for it.
There you go.
Requirements change mid-implementation.
Now it's problematic.
That's why we have, you know, Agile, so you can adjust fast and, you know, do all of that.
And we realized that, okay, we invested so much on the coding part.
Great.
But we looked at the metrics and the most simple metric you can always look at is your cycle time.
In theory, if you speed this up, the coding part, people would expect you to ship faster.
We have not seen that.
So it's not that we're shipping faster, we're shipping more, but not faster.
So there's a difference, volume or output versus outcome.
And in our case, we wanted to improve cycle time.
But to improve cycle time, you need to also automate the full cycle, meaning you need to automate how you get requirements, the product part.
How do you optimize?
How do you experiment fast, especially?
How you prototype and how you validate, right?
So one thing clearly that we've seen, ist, dass wir mehr PRs haben.
Und diese PRs sind jetzt groß.
Wir haben nicht wirklich die Regeln, die wir nicht für die Regeln sind, sondern für die AI.
Das war eine der ersten Ärzten.
Wir waren, ja, wir müssen die größten PRs haben.
Weil wenn es gut für ein Mensch ist, dann ist es perfekt für ein AI.
Und wir haben die Regeln.
which is the second part of the software development lifecycle.
So we started with the coding, went to review.
On the review, we now have also agents that review the code, right?
So we don't review ourselves.
We glance over it sometimes.
But there is actually a little bit of an architecture where we have a few curated agents that go into the PR once you open.
And these agents will check for very specific topics.
which are non-deterministic checks, right?
So we're going to look into SRE, like have you thought about your SLOs and SLIs?
Have you thought about your resilience mechanisms in place, like circuit breakers, book heads, etc.?
Or another one, another agent we have is security.
Have you thought about your security threat modeling part?
And if not, it will comment and block the PR.
Now, all of these PRs then...
haben wir ein LLM-judge auf dem Top.
So das Agenten, das auf dem Topf wird, für alle anderen Agents zu assessen, die Changes zu sehen und sagen, sind Sie alle in Konsensus?
Und wenn Sie, jetzt kann ich rank, ist mein PR Risky oder nicht?
Und wenn die PR ist, vielleicht muss ich ein Human sein.
Aber wenn es nicht, vielleicht kann ich Auto-Merch.
Und dann geht es um unsere actualen Deployment Pipeline.
So, there's a few of these checks.
Not every team is doing this today at Parloa, but a lot of the teams are adhering now to this way of deploying and reviewing.
And our developer experience team is going to push more and more of this throughout the organization.
But this, again, optimizes the review part.
Now, where is the problem if the review doesn't go well?
Your quality gets affected.
So this means we need to fix our deployment mechanism, meaning deployers have to be very low blast radius.
This is with or without AI.
We should always have this.
So as minimal blast radius you can have in your deployments, the better.
So think about Kender releases, feature flags, whatever else, right?
And after that, basically, we can release to the customers in a sustainable way, so a staggered rollout way.
This is independent of AI, but we need those things in place, these foundation things in place, to make sure that whatever AI changes that are produced and automated, as much as possible to be merged, can have the least effect on the customers if something goes wrong.
And then we have to automate quality back.
So that's always a quality loop, which is complicated.
And with AI, you amplify this, right?
With AI, you're going to see much more of this happening.
So your metrics are very important to look at.
Your change failure rate.
Take a look at that.
So what we've observed at Parlo is that our change failure rate was not necessarily increasing thanks to the guardrails we had, but we saw a little bit of a spike sometimes because of the amount of stuff coming.
And then you would see your CFR going up and then we're like, oh, something's off, let's roll back and let's see what we can reassess.
So a lot of that...
Es muss sich in die Lage sein, dass du das Grund hast.
Maybe we can dive a bit deeper.
My first question would be, is there the binding thing you developed?
So the way I understood this is like the kitchen, like it was like free of choice, so to say, like no one needed to use that, but like everyone was invited.
So when you switch to authentic engineering, so to what degree this is like one harness to rule them all or is there still some?
für die Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Teams-Te which is also not great.
Because even us, we don't have Cloud Code only.
We have Codex.
And, you know, some people still use Copilot, which is also fine.
And some people use Cursor.
So we don't want to enforce which LLM, which coding LLM we're going to use.
Right?
Like, we don't enforce that.
There are deterministic checks for a reason.
We call this the maturity model.
So if your service is at a maturity model of X and your HPR you open fulfills the same maturity model, how you get to it, it's less relevant, right?
So the kitchen will speed you up because there's a lot of harness there, which does a lot for you.
We have a lot of golden path stuff in place, right?
So we have like service templates and things that are completely independent from AI, but we already had it.
People can adhere to it.
Now, with the kitchen, you will be faster, probably.
But you can do your own harness, no problem at all.
It's going to be a lot of work.
And very likely, you will be slower than somebody using the kitchen out of the box kind of harness, right?
So there will eventually be a question like, is it worth it in terms of speed that I build everything here?
Or should I just use whatever harness is provided already by our kitchen, right?
Wir müssen nicht versuchen, dass du es, dass du es, dass du es schneller hast, du wirst schneller werden.
Und für uns, eine andere Sache ist, dass die Problem mit dieser Art of Harness ist, dass du eine Art von Harness entwickeln kannst, du hast es, dass du eine Art von Harness entwickeln kannst, du hast es, um eine Art von LLM zu entwickeln, um eine Art von LLM zu entwickeln.
Es ist wirklich schwer, um eine Art von LLM zu entwickeln, das ist sehr independent, um deine LLM zu entwickeln.
Du hast es für Claude.
Und dann haben Sie alle die Vorteile von Cloud.
Sie haben die Cloud Hooks, Sie haben die Marketplace für Distribution, Sie haben das Integrated into Cloud AI.
So jetzt kann man sich umpultiv your work nicht nur für Engineering, sondern für die ganze Organisation.
Wir sind jetzt an dieser Stelle.
Ich will noch mehr über das.
Aber, sozusagen, das ermöglicht, das ermöglicht, umpultiv your impact.
Und in unserer review, wir sind okay, wir können auf die Harness.
You can still use codecs, you can still use something else.
And things are being more standardized in the industry now, right?
Like even skills are getting to a level of standardization across the different LLM agents.
That we're like, you know, we're like, okay, you know what?
Maybe the LLM doesn't matter in the end.
The agentic choice that you have doesn't matter.
What matters is have this type of harness, you will be faster.
One interesting thing we did realize was that we were so dependent on Cloud Code.
And if you have been using Cloud Code, especially in the last months, you know how unreliable it can be in terms of resilience, right?
Like it sometimes goes down and then what happens?
Suddenly, everybody is like, oh, Cloud Code is not working, so let's get a coffee or something, right?
Everybody forgot how to code.
So we're like, yeah, maybe the productivity feeling is not there anymore.
So what we developed in the end was we created what we call the coding agent proxy.
So essentially it's a proxy that you provide to Cloud Code.
But if Cloud Code is going bad for whatever reason, it's having a bad day, it falls back into Codex straight away.
So it's a simple fallback, but it's a very useful one.
So developers, sometimes they don't even know that, you know, Claude code is down.
Some people which are very familiar to how Claude likes to reply, they of course know, but it doesn't break their flow, right?
Because we keep also the, we keep the context management really, really well done with the harness, that it's very transparent for the engineers themselves.
So that was really useful.
So it falls back into Codex.
You can fall back to whatever, honestly.
But basically we decided Codex because the results were pretty solid.
And also some skills mandate Codex to verify work that Claude did.
And that's usually a good strategy, right?
You mix your models here and there, or your agents, not your models, your agents.
And then you can have different perspectives on challenging themselves, which is how we get to consensus model.
So it's one thing we've done a lot in that.
Ja.
Das heißt, es ist wirklich nur custom-built, oder ist es auf, ich weiß, auf die Sprecher und Framework?
Ja, alles.
So ist es etwas, was du benutzt, wie ein Open Source Projekt oder du leverstestest, eine Existenz Technologie, oder ist es auf deinem eigenen?
So die Skills sind bei uns selbst.
der majority of them.
Of course, if you use Cloud Code, we also encourage you to sometimes use the superpowers, I think that's the name, or superhuman, I forgot.
I think it's superpowers.
Superpowers.
Superpowers.
So we also encourage you to use others which are out there, right?
Like, for instance, I'll give an example.
So we have TypeScript.
Why would we define a TypeScript kind of like best practice kind of skill if the community is doing that already?
So we just use that and we enhance with our stuff, for instance, how to do hexagonal architecture on TypeScript.
That's very specific to Paraloa.
We decided to use this architecture choice.
So how do we want the harness to be built around this?
So we specify that, but we don't define what good TypeScript looks like or we don't define what good Go looks like, right?
But we define the architecture that we want to be outputted out of it.
Like use repository patterns, use port and adapters, these kind of things.
And that usually comes to the benefit of our overall architecture.
So we enforce those things in the skill, but we use common skills in the market that are developed by the communities, especially when it comes to language.
So we usually, we do that a lot.
So it's not fully custom to your question specifically.
It's not fully custom, but there's a lot of things tailored to, Parloa, yes.
Because it helps us in multiple areas.
Sure, sure.
Yeah, and I think that makes a lot of sense.
The more I look into stuff, I now also move a little bit more towards community skills, or to put it blunt, the Matt Bocock skills are the ones I use mostly currently.
That's good.
Und dann einfach zu meinen eigenen Projekten.
Wie zum Beispiel eine sehr bestimmte Dokumentation Review.
Das macht eine Partei von der Review Flow, oder so.
Das macht viel Sinn.
Und du hast gesagt, dass nicht alle Teams benutzen.
Und nicht alle Teams haben die Review Flows gemacht.
Ja.
Für uns, speziell auf der lateren Seite, wie Deployment und so weiter, das ist Standard.
Jeder hat sich zu follow, weil es independent of AI ist, wie wir Deployieren, das ist, wie wir unsure, dass Code ist, die Kunden zu unseren Kunden und Produkt Value ist, die Kunden zu unseren Kunden, die richtig gut ist.
Das ist Standard über all Services, für sicher.
Was ist nicht Standard oder nicht Mandate, ist die verschiedenen Agenden zu Review-Eur-PR.
We have that in every repo, but some of them are not enforcing you to have consensus, for instance, or some of them are not enforcing you to auto-merge, right?
So some teams decided, I want to review still every single PR.
Okay, you can do it.
No problem.
Some teams decided, I want to auto-merge as much as I can.
So here we go.
So that is flexible to the teams to that point.
Of course, we have enough metrics to see adoption, like how many people are actually using.
The different agents we're providing.
How many people are using the kitchen?
How is that helping on the DORA metrics?
So cycle time, CFR, etc.
So we look into all those metrics.
Who owns most of this is developer experience today.
So the developer experience team here owns this whole flow.
So the kitchen plus also the agents that go into the PR.
Und nicht die Dora Metrics, sie haben das eine große Rolle, aber sie haben eine große Rolle.
So das ist eine große Rolle für uns.
Da ist eine andere Sache, dass ich ein bisschen mehr touched, was wir created the kitchen nur für engineers at the beginning.
Aber weil wir also moved into Cloud AI, nicht Cloud Code, ist jetzt Cloud AI, also accepts Marketplace, custom third-party Marketplaces, Plugin Mechanism.
We roll this out throughout the organization.
So there is a team at Parloa called AI Transformation.
It's a team outside of technology.
And the main focus of this team is to democratize AI for the rest of the org.
Remember in the very beginning of today's episode, I mentioned AI Native as a company.
And one of the reasons why we call ourselves AI Native is that AI is in every single department of Parloa in one way or another or in a shape or another.
Some teams at Parloa are using more, some teams are using less.
But even our legal team uses AI, right?
And it's very helpful to them into how to sometimes not assess something, but review something.
It's very useful.
For finance, into how to get and cater the right data, very important.
For HR, also very important.
So they also want to benefit from the kitchen or benefit also from certain skills that engineering has built.
And of course, once you open the gates for the company to start using that, questions will come and requests will come.
Hey, I just want to deploy this website out there.
Or I just want to deploy this little thing that we did.
And we cannot mix that with production code, obviously.
So we have a sandbox where everybody else can deploy stuff there, can try stuff out, whatever other departments.
But we never mix it with production.
Because production is ownership of engineering and product.
So, of course, we don't mix it.
But we do allow for them to deploy and experiment.
And the next level, which we're now also using, is the cloud agents.
So, on the cloud, especially after Anthropica has released them, we wanted to try that out.
We tried cursor cloud agents as well.
We tried Cloudflare.
Also, with its edge workers, you know, like all of that, and putting some Claude code in there.
So we tried everything.
And the thing that worked the most for us was Anthropix cloud agents themselves, for now.
Very likely this will change tomorrow, right?
It's so fast moving that it doesn't matter much.
The important thing is, what do we want to achieve with those agents?
And that's really the question.
Und wir haben eine Vision, dass wir uns zu kommen, dass ich eine Freude, dass ich eine Freude, als ich sage, ich habe diese PRD hier und ich muss diese PRD zu werden, und ich muss diese PRD zu werden, bei einem Monday.
Und auf einem Freude, auf einem Freude, du sagst, okay, ich kann diese PRD und ich kann diese PRD, bis es perfekt und bereit für werden.
Auf einem Monday, du kommst zurück und es sollte in der Produktion sein.
Das ist...
Das ist das, was wir wollen, dass wir zu kommen.
Und die Agents, die wir sehen, wir werden, wir werden Jura-Tickets, wir werden alles in Ordnung, wir werden die PRs, die andere Agents, die wir über die Vorstellung haben, wir werden das, wir werden das, wir werden das zusammenfassen, bis die PR ist der stage, das wir gerne.
Und dann, alle die Worktreten, die wir zusammenfassen, die Produktion zu kommen, und sehen die Ergebnisse, die wir können experimentieren.
Das sollte immer noch so wir können experimentieren in einem sizable way.
Aber das ist die Vision, richtig?
Wir können das mit heute's Technologie sehr schnell ausgehen.
Aber wie viel risk wollen wir mit dem?
Das ist die Frage, dass wir uns zu answerieren müssen.
Und wir haben nicht getroffen, dass wir das Punkt haben.
So die Dark Software Factory ist etwas, was folgt uns durch das Podcast.
Es ist immer wieder.
Wir callen die Dark Kitchen.
Of course.
So it's the same thing.
It's a dark factory pattern.
We want to make sure that we turn off the lights, everything will work and will be continuously working.
But in our case, the kitchen will continue working without the lights.
So it's the same principle, but with our kitchen theme.
What's your current take on when you will be there?
Is it a matter of weeks, months, years?
No, it cannot be years.
Ja, of course.
Because probably we're going to have something else in Cloud Code in a year or two.
My take is that we're in July.
And my take is that we're going to be able to be there in September for some teams, again.
But not for all teams.
Like I said, some teams would still like to review their own things.
Maybe the risk of certain teams are higher or risk appetite is lower.
It depends.
And we don't want to enforce this kind of ways of working until we prove it.
That it actually works well and we get confidence that this is how we want to release software going forward.
If we do this, the areas we need to invest a lot on is design.
So system design and everything around system architecture.
Which is why we like also to think about our engineers as product-minded architects.
So when we hire, the main principle we look for, are you product-minded?
Do you think about business acumen well enough?
Like, do you have a business acumen?
Do you think about the leverage of engineering in the business?
If you do think that, we can assess if you have this kind of product architect mindset, which will help us get to that stage that I'm talking about here.
Because the discussions we have internally is very interesting.
Like, we're not talking, we're not being pedantic about, like, talking like, hey, is this the right design pattern?
Maybe that's not the most relevant thing for us to look at at the moment.
But is this piece of software delivering the value that we actually need in a resilient and secure form?
Because that's really what matters.
The main SLO for Parloa is latency.
So we need to be very careful with latency, meaning whatever design we do has to consider latency as the main cost for us.
So thinking about latency is very important, but thinking about which design pattern to use internally in one single component might help latency or might not help latency.
So it really depends.
There is no silver bullet.
So for us it's very important that people start thinking about the systems and not about the specific component anymore.
So that's the main difference on how we hire also.
We need to look for people who think about the whole system, not about their own single little microservice.
Ich habe meine Betten, dass wir in bestimmten Teams können, vielleicht nicht zu all, aber nicht zu all, zumindest.
Aber du hast eine Pointe, ich denke, dass du da mit der Dezentralen Organisation bist, dass Resilienz ist, richtig?
The architecture is decoupled.
I'm wondering, like you mentioned latency as the core, I don't know.
It's me, SLO for us.
SLO, but there is probably more.
So when you think of quality, like function, non-functional aspects, who's defining that?
I'm wondering, it sounds great, right?
Giving teams the freedom to decide whether they want to use the kitchen or not.
On the other side, so if you do not define what is expected from them, I think who is more or less, I'm not saying controlling, but who ensures you're not going for usage or enforcement, but still you go for meeting certain expectations.
How do you ensure that?
Very good.
It's a collaborative approach, right?
Like there is no single central team that can enforce that because enforcement doesn't drive accountability.
But the important part is we do have a program around what we call QRS, right?
So quality, reliability, and security.
And this program is basically how do we empower engineer managers, basically, to have control over certain things.
but also adhere and be accountable to a certain level of quality, reliability, and security.
We call this the tracer features.
So for every feature, there is a bunch of things that you need to adhere to in each one of those areas that once you adhere to that, your feature is ready to production.
If you don't, your feature is not ready.
So your definition of done basically needs to include tracer features.
And that's very important, but that's not something we knew 10 months ago.
It's something we continuously developed and continuously improved as we went along the journey.
But a differentiator was we have a PMO in our organization, so a product management office, which helps us kind of like roll out these things holistically across all teams, right?
So from a project perspective.
Und sie helfen extremt, um die QRS-programm über die Board.
Wir haben sehr, sehr Experte EMs, die haben das schon gesehen.
So sie wissen wie sie wie in so einen Moment haben.
Und das ist eigentlich 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, Das ist ein reales Ding.
Wir haben etwas, was wir an Operational Excellence Guild, wo die EMs gehen, und sie reporten auf ihre SLO, und sie sagen, ja, ich bin meine Budget hier, meine Error Budget, die bedeutet, wenn ihr Error Budget auf ein bestimmtes Level ist, ihr nicht mehr Produktionen zu können in einem bestimmten Service oder sogar einen bestimmten Produkt.
Das ist ein Agreement zwischen Engineering und Produkt, Us in leadership, we aligned and make sure like, this is where we want to go.
This is where our customers expect excellence, right?
So they expect nothing less, but very good reliability and very good security to deliver that.
We need those mechanisms in place to ensure that we can fast forward with AI, but in a secure and reliable way.
So to us, this was the unblocking mechanism.
And it's not perfect.
Till this day, we have problems.
Und wir müssen diese Probleme immer wieder fixieren und dann weitergehen.
Wir haben keine Wund und eine Wund-Recipe, die sagen, das ist perfekt und funktioniert.
Nein, aber das funktioniert für uns bis jetzt.
Es funktioniert gut.
Ja, aber du hast einen guten Wund.
Ja, absolut.
Aber du hast gute guardrails in place.
Und ich denke, das ist auch noch wichtig, wie ein Alignment zwischen dem Produkt und dem Technik.
Was ist wichtig, right?
So, wenn man eine Seite für excellence ist und die andere Seite für, ich weiß, speed ist, ich denke, das wird nicht gut sein.
Also, es ist die typische, die typische Tripod der Produkt, der Produkt-Management.
Du kannst für Speed.
für Kosten und für Qualität, aber Sie können nicht alle drei zusammenarbeiten.
Es ist fast unmöglich.
Es ist fast eine Kaptheorem-Kind-of-Idea.
Ja, das war sehr dense, wirklich cool und sehr rich in der Details.
Und wir definitiv müssen das in der Zukunft haben.
September ist in der Kalendarsen.
Und ich denke, wir müssen die Schlussfolgerung.
weil wir also müssen Ende Ende kommen.
So, wir gehen zu den Segments, die wir immer haben, am Ende der Episode.
So, die Reality Check.
So, was sind die F-F-F-Situationen, die du immer noch mit AIs hast?
Und was ist die Hot Sh-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F-F- Let's call it the most surprising thing for us with AI is how much stupid thing it can produce.
So we're like, not just AI's lop, because everybody knows it does produce, but if nobody's really understanding or caring about what it's producing, it can ship so much wrong stuff.
So that's why you need to invest in your harness much more.
So we only realized this, obviously, after a lot of things that we shouldn't have shipped in the first place.
But not only that, but also, you know, if you think about AI for a second, it allows you to democratize a lot.
We have a whole VoIP stack, which is very complex and difficult from a skill set perspective.
With AI, you can democratize that, right?
So in theory, anybody now can touch VoIP really easily.
Ja, das ist nicht wirklich wahr, weil wenn sie sich schicken, wenn sie break ist, das ist die Moment, dass sie sich nicht mehr wissen, dass ich nicht mehr idea was, was ich eigentlich ist, und ich bin ein Experten.
So für die Leute, die sagen, oh, you know, bestimmte Engenhezer werden, und so weiter, ich denke, sie werden nicht mehr.
Ich denke, sie werden auch nicht mehr.
Ich bin viel Fan von dieser Evolutionary Architecture-Kind-of-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea-Idea- Specific skills now are rising and people are evolving in their skill set, which is very, very important for us to also, you know, use.
And that's why I think a good mix between experience and innovation, it's very important.
Experience comes with everything you've seen in your career and now you know what good looks like.
But innovation comes with, oh.
This is actually super cool and I'm curious.
And that's why I like to foster engineering culture where curiosity is one of the main things that we should keep fostering across the organization, right?
Be curious.
Because once you stop being curious, it's not fun anymore.
And you're just in a, you know, autopilot kind of mode and you don't innovate.
It's simple as that.
So to us, that was a realization on the AI side of things.
If I would say, what is a prediction?
I don't really have a prediction because the market is moving so fast.
Not my prediction, but let's get back into the dark factory kind of model.
I think what we thought as Parloa to be a differentiator, like, hey, we're doing a lot with AI, probably more than some other companies could potentially do because we are in this AI native environment.
This is not a differentiator.
Everybody has the same opportunity, maybe at different scales.
So what can we do as Parloa that actually is the differentiator is hire the right people.
That's for us the most important thing.
Our ISP is hire the right people because these people are the ones that will evolve with you as the organization evolves, foster a good engineering culture, then forget about the technology because they will adapt to the technology.
That's how I think about it overall.
So, not really a prediction, just a realization.
Makes a lot of sense.
Well, thanks a lot.
Thanks a lot.
Thank you.
It was a pleasure.
It was very good talking to you.
Thank you.
Absolutely, likewise.
What a great episode.
And as always, at least for the last times, so let's have a recap, was what stuck with us.
If I may start, I would say what definitely stuck with me is their approach, starting with the kitchen.
sehr leichter, so zu sagen, sehr optional und dann turnen das in eine solitaris.
Definitely, definitely a great, great approach.
Ja, absolut.
Found this also super interesting and they were pretty early on, right?
He mentioned that in Feb or so, when Cloud Code came out, they started to adopt it, right?
And they immediately started to write their own skills.
So it was really und wirklich cool zu hören.
Und die follow-up von diesem, für mich, ist die Automation von Software Development Lifecycle, wie sie approachen das, in der sehr structured Art und Weise.
Wir haben auch mit anderen Diskussionen, die auch gesagt haben, ja, Coding ist super fast, aber Reviewing ist die Problem.
Das war 4 Monate zurück, wenn wir, zum Beispiel mit Uli von Mapboxen, die für sicherlich haben auch solutions.
Aber die Das ist die Art von der Bühne, die nicht nur Coding, aber auch Prototyping und Deployment und was nicht, ist sehr Structured und sie einfach nur die verschiedenen Angeln, die verschiedenen Dimensions haben, die sie zu checken haben, die sie zu tun, die sie zu tun, die sie zu tun haben, die sie zu tun, die sie zu tun, die sie gut oder nicht, die sie mit den Threshold treffen.
Und dann, und das ist die typische Human-in-the-Loop-Methodologie, wenn es sehr wichtig ist, A human has to look at it, right?
That is really impressive.
And I think, yeah, that's how you do it.
Period.
And maybe to just add to that, again, and will be my second takeaway from the discussion, the flexibility.
I think when it comes to the review and the deployment, I think they are very, very strict, right?
They have their standards, but everything before, at least.
Das ist mein Hinweis, mein Verständnis.
Es gibt viel mehr Flexibilität in der Prozess.
Also nicht eine einzige Harness zu ruleen, aber wie zu beschreiben, vielleicht eine Offer.
Also vielleicht auch die beste Offer du kannst.
Du kannst du etwas auf deinem eigenen, aber dann sollte man gut argumenten.
Ich bin nicht 100% auf der Idee.
Ich denke, das ist gut.
Ich bin nicht sicher, wie es funktioniert in der Praxis.
If that works in practice, that is awesome, right?
Yes, I think it depends a little bit on the constraints, right?
So they hire aggressively, hire specific type of people, right?
They also have a lot of money, which means that an enterprise deal with one provider is not the main focus of them, right?
However, I still think that flexibility for engineers, the freedom to use the tool that you're really comfortable with.
ist das auch ein sehr viel, und ich würde auch versuchen, zu haben diese Flexibilität für meine Organisationen, so viel wie möglich.
Was ich auch aus dem kleinen Proxy, die sie ausgedrückt haben, weil sie ja, Cloud kann diese Probleme haben, und sie haben jetzt eine Fähl-Over, via ihre eigene Proxy zu Codex, wenn Cloud ist nicht möglich.
Ja, super easy, super smart.
Proxies are something that generally make a lot of sense.
I think we had this also in one of the previous episodes.
And I would also, this is definitely a topic I also want to look into.
Also for other reasons, in a proxy you can do much more, right?
You can track usage or spend across the whole organization.
You can even do, if you want certain checks in a proxy, you shouldn't do this like more than it.
Aber das ist ein einfaches Failover, ich denke, eine gute Idee.
Eine gute Idee, absolut.
Für mich, aber nicht nur die Leidenschaft, ist es der Pass zu einem Dark Factory oder vielleicht in der Organisation, sie sich das Dark Kitchen an.
Das, von meinem Punkt, eigentlich macht es Sinn.
Starting with a very lightweight approach and then turning it into a harness and then turning it into a dark factory, really, I think it just makes sense.
So really looking forward to having them here again in September and better understanding where they are, what their learnings are, and maybe what we then also experience outside from the market, right?
There will be also changes.
Absolutely, yeah.
I'm pretty sure that they will do it in a safe way.
Describes it where like they have the deterministic checks before anything hits production, right?
So that thing is covered anyways.
And now they need to nail the PRD and have the acceptance criteria.
So the pretty much tests right and clarified and then structured out well enough.
Then that might really be possible.
Let's see.
Yeah.
And maybe to add to that.
Es ist eine Organisation, richtig?
Sie haben, wie Sie gerade gesagt haben, sehr specific Leute.
Sie haben eine Alignment mit der Produkt, was wichtig ist.
Ich denke, sie haben die besten Prerequizite zu wirklichen.
Ich denke, Sie sollten nicht nur das LMS-Esteigen.
Ja, absolut.
Und noch etwas.
Sie haben das als Teil ihrer Efforts zu have something uniquely special or their secret sauce basically, right?
They're hiring, so what's their differentiator?
And I think another thing that makes them different is the very fact that they're AI native and that they have an AI transformation team to transform the whole organization.
How they approached it, how he described it was very cool, very interesting.
Of course, you need to have a certain size so that you can afford to have such a team.
Aber das ist ein Thema, das ich auch mit anderen Leuten diskutiere, sehr lange.
Es ist nicht nur die Ernehmung der Rest des Kompanyens, sondern auch als nächstes Mal, wie man sich das Automatis, die sich zu leben, sind wirklich gearbeitet und sind wirklich gearbeitet und nicht in einem technischen Debt, in sechs Monaten in der Zukunft.
Super interessant.
The Beyond Vibe Coding Podcast is a project by Sebastian Heidemalze Erpen and Andre 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.