# Agentic Engineering Governance and Quality Frameworks

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

## Transcript

My main concern or sometimes question marks for AI is like it's 80% accurate, right?
And for me, I do have expectations on the organization to be excellent.
And when you're excellent, you cannot be 80% right or 90% right.
Like that 5-10% is what I feel very strongly about.
Welcome to another episode of our new season of Beyond Vibe Coding, partnering with Impala Search.
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 Heidelmeier zur Erpen, CTO at Ecosia.
And I'm Andrei, CTPO at Trusted Shops.
Great to have you back.
Today, it's time to dive deeper on Agendic Engineering again.
And we do this with Yeni Cheng, VP Engineering at Bluefish.
Yes, and she shares very openly the structured approach to Agentic SDLC at Bluefish, not just in engineering, but also beyond.
It's quite interesting.
I could relate a lot to what she shared.
Und ich hoffe, es ist relativ zu Ihnen, auch.
So, bitte, enjoy die episode.
Willkommen zu unserem Podcast, Yeni.
Wir sind sehr froh, Sie zu haben.
Und als usual, wir möchten Sie uns zu uns zu unseren Listenern.
Mein Name ist Yeni Cheng und ich bin VP of Engineering at Bluefish.
Wir sind die Agenten Marketing Platform für Fortune 500.
In meinem Beruf, ich habe auf dem Berufs-A- und Szenen von Szenen gesehen, die ich ein paar Mal auf der Verkaufung habe.
So, wenn ich in ein neues Unternehmen in einem neuen Unternehmen, wie Bluefish, mit einem schnellen Trajektor, habe ich eine Chance zu machen und zu bringen, die ich vorher hatte, zu nutzen.
On the side, I also do some angel investment.
And the goal is to stay close to the startup ecosystem, as well as to meet with a lot of high-energy entrepreneurs to also get a scoop of the latest technology and where the landscape is going.
Thanks a lot.
That was very taught and crisp.
Und short and crisp, exactly, yeah.
And we have a couple of segments usually in our podcast.
The first one being the status quo, where we ask our guests to briefly describe how they are utilizing AI in their day-to-day work.
So interesting for us would be both either non-engineering or engineering use cases.
Yeah, please let us know how you utilize agents or LLMs in your day-to-day work.
Ja, mostly I do automation for engineering management work.
That includes meeting summaries and recording action items.
I also use it as a co-pilot.
So I have it send a daily digest for me, looking through Jira, the latest changes in Slack, several channels that I'm interested in, and on emails, things that need my urgent attention.
And that has been quite helpful now that we have an organization of around 40 engineers.
Ich finde mich manchmal manchmal missen auf die wichtigsten Gespräche auf die Zeit.
Ich kann das als ein Co-Pilot und vielleicht erstellen einen ersten Screen.
Ich weiß, dass die Teammitglieder es einen Schritt weiterverteilen.
Sie nutzen AI zu triage Slack und Chat.
So, du hast eine erste Level von auf-denken und Antworten von AI.
Ich denke, das ist ein weiteres Worte in der Progression.
Ich glaube, Sie sind ein A.I., aber das ist etwas, was wir auch noch explore.
Vielen Dank.
Ich habe auch noch eine Unterricht für zwei Wochen oder so gearbeitet.
Ich habe genau das gleiche gemacht, mit dem E-Mail, Slack, Confluence, was auch immer relevant für mich.
Ich muss sagen, dass das wirklich, wirklich hilft.
Ich weiß 80% von es, aber es gibt noch 20% von es nicht.
Und dann habe ich alle Details in einem document.
Ich kann immer referieren.
Und das cool ist, dass das document dann ist die Basis für eine Woche-end-Review.
So ich kann dann sehen oder versuchen, Patterns zu finden, das dann ist dann von der Agent.
Und dann, Ich bin noch nie bei Ecosia, aber ich plan, um das noch mehr aggregativen, um so ich sehen, dass ich größer Themen weitergleiche, um die Themen zu sehen, um die Zeit zu überwinden.
Wir haben das gehört, aber jetzt, für die ersten Mal, ich habe das hier selbst.
Und ich habe das hier absolut gerne.
Das ist toll.
Ich möchte mich auf Ihre Frage auf die Widerthemes.
Awesome, that sounds great.
Yeah, I think this is the right type of task for it to do.
My main concern or sometimes question marks for AI is like it's 80% accurate, right?
And for me, I do have expectations on the organization to be excellent.
And when you're excellent, you cannot be 80% right or 90% right.
Like that 5-10% is what I feel very strongly about.
But I do feel like this daily summary is what...
Es kann nicht so, ich glaube, es ist nicht so, ich werde es nicht so, ich glaube, es ist mehr so, ein erstes Brief für mich zu klicken und verstehen.
Aber wenn ich nicht das Brief habe, ich würde mich nicht mehr auf das Kontext haben.
Es ist mehr so, es ist ein wichtiger Punkt, und ich denke, das ist ein wichtiges Differenzierung und das ist etwas, was wir auch noch darüber sprechen, die judgmentalte AI und die Mache taste.
100% und das ist, ich denke, ein sehr important Punkt, das ich auch mit meinen Engenern über und über again habe.
Very low risk uses for AI where you can just like, as you mentioned, this is just enriching the context of our work, right?
So if we don't see it, we will just not see it, right?
And if we get additional information, then that's helpful, right?
But there are other areas where outsourcing this entirely to AI, let's say a complete planning process, complete strategic analysis, whatever, right?
Then we are really entering.
A field where we are lowering our bar to the average of everything that the humans have seen in the past.
So we need to really utilize AI to its strengths and not everywhere just because we can.
Yeah, definitely.
Thanks a lot.
And now I think it's time to enter the main section.
And the main section today is about, yeah, pretty much I would say agentic engineering, but not just like engineering.
within Engineering, but also across the org at Bluefish, right?
You shared a very interesting slide deck with us beforehand, which we'll not show, but we'll go through basically the main contents now.
And yeah, hopefully our listeners get a lot of insights out of this.
Yeah, so please let us know how you approach agentic engineering at Bluefish.
So from our perspective, Bluefish works with many of the Fortune 500 customers, and that means our output quality, data protection, and compliance is the baseline.
And that also informs us on our strategy and our approach towards AI.
We cannot just throw away quality for speed, right?
We need a stronger framework on when our team's judgment needs to come in so that we can continuously keep that bar high.
And that's why we, the way to think about that is more triage different tasks into different category for things that are monotonous.
Things that doesn't require a lot of creativity, then those can be handed over to AI.
For example, incident first touch, right?
Like the first layer at which we get alerted and the first investigation can be offloaded.
Some common or repetitive CICD fixes first pass on PR review or creating certain monitoring dashboard.
We have skills to tackle that.
One interesting highlight is our team has a humanized skill as well.
So that's a bit easier to digest AI generated content.
And then you have a group of tasks that is more human in the loop in flavor.
So that includes, that might touch on some of our production use case of AI, right?
We have an eval process, continuous evaluation.
So while it can narrow down the set of items, right, for us to review.
Wenn wir das als Human-Termin reviewieren, müssen wir das Thema entscheiden, was wir mit dem Daten machen können.
Das ist die erste Partei.
Da muss man einen Judgment in das.
Auf dem Writungs-Termin-Code auch.
Einfaches kommt aus dem Planung-Phase.
Und in dem Writungs-Termin-Code-Phase, wir brauchen Human-Termin-In-The-Loop-Phase zu checken, ob es es geht in meiner Richtung oder nicht.
In meinem Gespräch mit den Engenern und der Workflow-Termin, eine Schottung ist nicht recommended, Now our code base is also increasingly sophisticated.
So just one shot and letting agents to do their thing kind of amplified mistakes when the first basis and foundation isn't being checked.
So that isn't quite working out yet, which is where it leads to the third area, which are tasks that are more human-led.
A lot of that comes down to planning, RFC, ideation, right?
So like the writing itself, you can outsource, right?
Das ist das erste Kontext, das ihr in den Niemann nicht beherrscht.
Das ist das, Sebastian.
Das ist das, was wir uns sagen, unsere Judgmentalien einfach nur an und an und an.
Ich persönlich bin sehr allergisch zu das.
Wenn jemand etwas etwas ist, das ist AI-Thought, in der Beginn immer so etwas posh.
Es ist so, wie die Vokabliore matchs, oder wenn du es um eine Deck ohne Kontext zu geben, dann auch das Erfahrung.
Aber das ist das, was die Das heißt, dass wir die Start Railen in der Management Team auch programmatically beobachten können.
Das heißt, dass wir eine Pattern hier sehen können, die mehr leften die Task ist, so in der Prozess, die mehr Menschen sind.
Historically, wir haben auf Code Review zu transferieren, also RFC Review.
Aber insofern, wir sehen uns die Team von der Engineering zu viel mehr Zeit, vielleicht 70-80% auf der Planung.
So what they would feed into Claude and having group sessions to review that bit, right?
So that in the end, when they sit together to do the code review, people already have context because otherwise the volume is too high for people to understand.
And we're not at a stage where we review line by line again, which is interesting because just three months when I was sitting on a panel, I think I was still feeling very strongly that we should review code line by line.
But from the speed at which things are moving, I don't think this is possible.
So, das ist eine Sache.
und dann absoluten, auf 80, 90 oder 95 Prozent, aber eigentlich nicht gut genug.
Also absolut, get what you refer to.
Und dann in diesem Prozess, was ich sehe für die Teams, die besser machen ist, wenn sie die Leute denken, wie die Arbeit für AI und nicht die Arbeit.
Und ich denke, das ist die Planung, die wie man die Schöpfung auf die Schöpfung in einem Weg kann, oder vielleicht TestSuite kann, kann man sich mehr einfach verletzieren.
Ich denke, das macht all die Unterschiede.
Und in der Endeffekt, das auch translates zu Co-Review.
Eine der ersten Feedbacken von der Team ist, dass es zu lang oder zu complex für jemanden zu reviewieren ist.
Und das hat eine Menge...
at our principal engineering level, because the more senior someone is, the more they are suffering from this reality.
The people who care most are suffering the most in this reality.
So I think it also took us several iterations, and I think this iteration is still going on what is the new practice and how can we create the incentive scheme to To set this straight, because otherwise the people who care most are the ones that suffer the most in the system.
Are you following a certain model to drive agentic engineering?
Or is it, have you defined the North Star for the organization?
So how does this work?
Because I think there are some people who...
As always, right?
So the people who are curious about the new stuff, giving things a try and improve.
But I think as an organization, you probably don't want to rely on that.
So is there some kind of non-star where you want to bring the organization?
Yeah, I would say right now we're still in experimental phase and we're experimenting with several guardrails and governance as well.
So we do need to have a degree of governance.
In terms of usage, cost, and the degree at which we are exposing maybe information to the AI, what I would say is I encourage pockets of experimentation within teams, right?
But then we have, so after the team has some time to evaluate, for example, Git Work 3, that's a good idea.
They show it in knowledge sharing, then okay, we make this more of a standard.
We start adopting that as a whole.
Wir sind ein paar Dinge, aber wir haben diese Schritte.
Wir geben auch ein Flexibilität.
Vielleicht müssen wir erst einmal auf den Technologien, aber wir haben die Technologie, aber wir haben die eigene eigene Prozess, aber wir haben diese Schritte.
And then later on, we think about how to enforce and how to incentivize the right behavior.
But I think that's important to get right because I don't want people to also feel like they can't try out new things.
I think it's a fine line to balance that they can, but at the same time, at one point, then we have some guidance in the organization because we have seen a couple of cases, right?
Kind of A-B testing in different teams on what works and what doesn't.
Yeah.
Sorry, André.
So one question that pops up in my head is you put a lot of focus on the governance, right?
And being actually compliant, right?
How do you implement this?
Can you give a couple of examples on how you enforce this compliance?
Ja, eine Beispiel ist mit der Business Team-Use-Case.
So, da ist mehr governance, dass es eigentlich needed ist, weil wir eine Audience-Ausbildung haben, das historisch nicht trainiert, um zu produzieren.
So, wir können nicht nur, um, für die Dinge, die man denkt, ist mehr verständlich für die Engineering-Team, es kann nicht translate.
So, das heißt, die Regeln müssen mehr in place sein.
So, für example, wenn...
So we now own the CICD and the deployment part of the skill library.
We have given some members in the business team GitHub access, and we have created a set of skills and automatic checks as well to make sure that secrets don't get committed, API keys are not exposed, right?
So these are the guardrails that we have.
Some of them deterministic, right?
It doesn't need to be LLM to make sure we have a check before this code goes into production.
And at the same time, that environment is completely separate, right?
So they don't have any access to the actual production code base, but we have a separate environment that is left for the skills.
Where we come into more difficulty is on hosting such apps, right?
So what we successfully navigate is skills and local distribution of application.
So through GitHub, right?
But then if we actually need to host them, our concern is that, well, but then this app might need to be exposed to the internet.
And how can we make sure that these pathways are vetted or this is safe, right?
Because then there is also some manipulation of certain sensitive data.
So that is the part that we still need to crack.
But we have also seen different tooling in the market that we can potentially buy.
So this is a...
Wir haben jetzt die Moment.
Ja, gott.
Wir haben uns die Gedanken in die gleiche Richtung.
Wir haben auch mit unseren Design Team und den PMs gesprochen, wie sie ihre eigenen POCs können und testen sie.
Wir haben eine Infrastruktur in place, wo wir bereits haben eine Menge Automation, damit es eine bestimmte, um eine bestimmte, um eine bestimmte Struktur.
Das ist nur für Ecosia-Employen, das ist dann sehr safe, um zu deployen ein POC zu deployen.
Oder von GitHub, wir können automatisch sete die Infrastruktur, um dann testen die POC zu testen.
Das macht es einfach.
Aber wir müssen in die Skills zu investieren, um zu verbessern und die Veränderung und die Veränderung des Sie bereits erwähnt.
Ja.
Got it.
Das ist cool.
Wir können die Nodes späteren.
Das ist wirklich interessant.
Und eine andere Frage.
Du hast auch gesagt, dass du e-VALS bist, wahrscheinlich für die LLM-Use-Cases in deinem Produkt.
Oder bist du auch in anderen Plätzen?
Ja, so in der Produkt, das ist die erste Use-Case.
Wir brauchen die Evalu-Age.
Das ist, dass das Agenten ist auf point.
Das ist, dass wir auch mehr sicherlich auf die Funktionality weitergehen können.
Ja, gott.
Ich denke, das ist, für mich, ein bisschen der Holy Grail.
Ich denke, es ist ein Agenten, das Sieben, die einfache, dass es einfacher zu evaluieren ist.
Aber es ist schwerer zu evaluieren LLMs, als ich finde, für mehr generalen Engineering.
Es ist so divers, so wie die E-Vals aussieht.
Aber für einen solchen Agenten, das macht viel Sinn.
Das ist eine gute Idee.
Die Partie we choose to centralise sind diese, die ...
More specific in use cases.
And the principle follows the way we build software.
Like, for example, how we test our pipeline.
Sometimes it's also not just one step on the eval, right?
We break down smaller tasks.
We can also use cheaper models, by the way, in this format.
And then we can test each step.
So the way we experimented with the KTLO Asian is also the same.
There are different thoughts on, you know, how ambitious we can take it.
Like, we can do more end-to-end tests.
And perhaps, like, can we be at...
Ja.
I see.
And do you have one or two examples what the KTLO agent is doing currently?
And is it triggered automatically or is it triggered manually?
Yeah.
So like, for example, it's linked to also JIRA, right?
So like when we create a task over there, we can tag the KTLO agent and then from there it creates the entire workflow and then you have the PR ready for review.
But there is a high threshold on when the KTLO agent would take on the task.
So that ticket needs to be well written.
There is no ambiguity.
And it's something that internally we have some rules to set.
It needs to be below a certain number of lines.
So we make sure that these are very compartmentalized tasks.
Awesome.
That's also a great approach of pretty much automating these monotonous tasks.
Exactly.
So that will be the first category.
It's the starting point of a factory, essentially, for the very easy, simple task.
Yeah, I'm very excited how this will influence our DORA.
So in the end, the way I'm thinking about this is also looking at outcome metrics.
This is maybe the middle column.
The first column is just the usage of AI, which we also look at, but we don't optimize for that.
Otherwise, we set the wrong incentive and then people token max.
And then there's a middle column for me, which is to look at some of the output metrics, like number of PRs, deployments, so on.
But there's the outcome metrics on how to solve the business problem and the more top-line metrics that we report on month over month, like Dora included, but at the same time.
Maybe thinking about, okay, with the same number of people in the team, did we manage to serve as more customer and try to make that relationship right?
Yeah.
And this is also a very interesting point.
Also, to some extent, a point of contention, right?
Do you, if you look at the metrics overall, I mean, you probably see an uplift in the output metrics, right?
So that everyone is seeing this, but do you also, can you correlate this with an uptick in outcome metrics?
Outcome metrics in terms of engineering raw power has been going really well.
But at the same time, I don't know if I can make a strict correlation to prove that this is because of exactly what task.
What I can see is it enabled a new mode of working.
For example, we are going into a demo with a customer.
Three business days, we need to whip up something that can really impress the customers to showcase our functionality, but maybe the UI isn't as catered for this use case.
We can spin up something real quick in a way that is isolated from production enough to put something quickly together as a POC.
That is something that the capability wasn't able, we weren't able to do that before.
But moving business metrics, did we close the deal?
then I think this still needs a bit more time to materialize, right?
I think it's also hard to create this kind of correlation.
So at least I have made the same experience as you 100% as you described it.
I think what you can influence is cycle time.
You can influence it a lot.
So a different way of working.
Und deswegen haben wir die Chance, um die Impact zu schaffen.
Aber das ist es.
So, es ist immer anders.
Aber die Lägel ist es immer wieder.
Und das ist, was ich gerade fokussiere.
Ich denke, die Correlation, insbesondere auf Revenue oder so, ist das ziemlich hart.
Aber wir sehen, dass wir da.
Das ist das wir sehen über die Industrie.
Uber reported on das.
Für sie ist es hart zu verletzieren.
Und auch Spotify.
Das ist warum sie mehr auf den Kosten auf den Kosten.
So alle verstehen, dass wir nicht und nicht wollen, weil es logisch ist, dass es value in being able to generate mehr output.
On the other hand, you need to generate the output at the right level of quality, right?
And then see if and how this translates actually into a revenue uplift.
And this is probably something that no company could show yet, right?
But at least, I mean, the logic that more output generates the opportunity for more growth.
I mean, that is just a valid logic, right?
Ja, ich denke, um die erste Prinzipien und was man kann, mein größtes Wissen und Wissen ist die Cross-Team-Collaboration.
Historisch, es ist wenig, dass, in unserem Fall, dass Engineering ein Blocken ist.
Wie ist es, dass wir nicht experimentieren fast genug haben?
Wir werden nicht die Feedback accurate genug haben.
Aber wie es so, wenn man einen Kunden spricht, sagt man, ja, alles ist gut, aber man will es nicht mehr.
Was das bedeutet?
Das ist ein bisschen das, was wir nicht mehr machen.
Solve that problem more end-to-end.
It's where we need to get to, right?
So what you mentioned, Sebastian, on maybe prototyping for product design that goes towards that.
What we're doing also is making the transcript nodes more accessible across the org and iterate faster there.
Can we use Agentic?
power to summarize content that's better suited for different audiences.
I use this quite a lot.
It's again one of these things that AI does pretty well.
But if we can, can we extrapolate that to final business results?
I think not yet, but I think from first principle that totally helps because that's usually the main blocker on velocity.
And I see velocity very end-to-end.
That's so just we delivered something.
Yes, very true.
Very true.
Ja, awesome.
Und dann in your slide deck, I think you mentioned also, and before in our talk, you mentioned that it's going beyond purely engineering.
You also gave some hints there, right?
And you mentioned some skills.
So there's a skill marketplace that you are providing, right?
Yeah, could you go a little bit into detail there?
So how it looks specifically for non-engineers?
Ja, so wir haben Teams, für example, die Customer Success Team, das arbeiten mit Kunden.
So ein paar Worte ist zu also caterieren, ein paar Intelligenz, das wir geben, zu einem Kunden zu einem Kunden.
So sie machen viel Automation auf wie sie beinwenden Kunden und schreiten eine hyper-Personalized Erfahrung.
So sie haben eine Skill.
oder Skills Marketplace, so dass sie sich um die Workflow zu entwickeln und die Werteilung von ihrem Seite zu entwickeln.
Und sie eigentlich haben die Entwicklung dieser Skills, weil sie die Konsequenzen zu den Problemen sie wollen.
Und von unserer Seite, wir acten als die Regier-Guard-Rail-Layer, zu gestalten, als die Veränderungen auf die Veränderungen, Das ist wie die Marktplätze, die sich in den Weg zu sehen, ist auch zu sehen, dass es eine bestimmte Standard auf das Fronten gibt.
Das ist wie die Marktplätze ist.
But more to see, for example, we have a case where a teammate once ran a very expensive model, maybe Fable, on some document analysis, right?
And then we racked up a bill that was like $750 an hour.
And with that type of case, we also now started actively monitoring the cost.
Und dann machen wir das mit dem Rigger wie wir es mit Software Availability machen.
So dann können wir das erst mal.
Und dann, bei den Fällen, wir auch analysieren, okay, wie die Leute tatsächlich benutzen diese Technologie so dass wir best provide guidance können.
Eine Sache, dass wir jetzt die Default Model setzen können, so dass es weniger accidentalen Usage gibt.
Und gleichzeitig, wir können auch eine Organisation-Prompte machen.
that actually gets appended to everybody's prompting so that we can also add some instructions for governance.
But these are the things that we find out as we provide this sandbox or the environment for our business teams to operate in.
Yeah, makes a lot of sense.
Do you also allow these, how you call it, non-technical areas to develop?
Maybe for internal usage?
Or how do you approach that?
Because if you give people this superpower, everyone is able to read and write to produce software.
These people, as you just explained, usually do not understand what software engineering is also about or the non-functional stuff.
But how do you ensure the platform is not suffering from that?
Ja, das ist ein wirklich guter Punkt.
Ich denke, es ist ein Punkt, dass die Linie der Linie ist, dass die Team der Team beantwortet ist, weil es dann geht es um ihre eigene Maschine, und es ist ein Mensch in der Lübe, in der Prozess, wenn sie das machen.
So für Tools, für Beispiel MCP-Wise, in der Engineering Team, wir haben sie, aber sie können das für ihre Workflow nutzen.
Das kommt an interessantem Problem.
Ich war in einer Konferenz und habe mit verschiedenen Engineeringen mit anderen Leuten gesprochen, und wir haben eine similare Problem.
Bord ist eigentlich gut an bypassing limits und hacking uns.
Wir haben eine Chance, dass wenn wir API Endpoints oder Tools expose, dass Bord hat eine Art und Weise.
Das ist ein Problem, das die Angelegenheit der Team muss, nicht in der Sinne, dass es nicht so bad ist, weil die Kunden auch werden will, die auch gleiche sind, die wir uns auf die Software haben.
Ich denke, die Bar auf Datenavailability, auf Daten-Based-Technologie, muss sich mit dieser Pattern auf wie man accesses Tools, wie man accesses Daten, auf unsere Produktion environment.
Aber das wir müssen kontrollieren, dass wir nicht das zu den Business user haben.
So mehr als die Pact zwischen uns oder die Contract, wie Rate Limiting oder die Weise wir die Manage Database, das muss man sich über die Welt zu verleihen.
Absolut.
Ich denke, Sie müssen eine Plattform, was das ist, wo ein Business kann verleidete Ideen oder run Ideen ohne die Überraschung des Busses.
Ja, für sicher.
Aber ich denke, das ist ein guter Use Case, weil es ein guter Drinking-Your-Champagne-Problem ist.
Wir sehen die patterns, wie unsere Kunden nutzen die Plattform durch unsere internalen Usage.
Und das ist telling und das gibt uns mehr Zeit für den Use Case.
All right.
Danke, Janne.
Wir haben die wichtigste Punkte, oder sind die Punkte du gerne zu adden?
Agentic Setup, the SDLC.
I think the last bit is on how we plan to scale by spending smartly in the future.
We haven't yet put in a lot of energy into that yet, right?
But we envision a gateway that can control the types of model we use in automation and productivity could be the way to go because we do that already.
to some degree in production, picking the right model for the right task.
So if we have a smarter way to triage that, I think that can be the next stage of optimization.
But I think right now we're still, as I mentioned, more in fostering that experimentation and fostering creativity there.
But that can be the next step that we will take.
Actually, my thoughts are going in a very, very similar direction.
Gateway would enable certain also security measures, right?
We discussed with Cesar of Miro, who has been doing also utilizing a tool that has been then analyzing the prompts for things that are actually out of the bounds of the ordinary, right?
And then alerted.
Like you mentioned, right?
Could route to different models.
Do some other observability things there.
So that's something we're also looking into.
And then on the other point that you made, I currently call it the company harness that I'm looking to build.
Pretty much very similar, right?
So a collection of skills or some skill.
like a skill marketplace, maybe with sub-marketplaces where we have one for design, one for product, one for the data teams, whatever, right?
And this should already contain then a lot of the helpful best practices, all the stuff that we utilize in our day-to-day work, some workflows that even include already a model, kind of a model selection, right?
So if you are in the planning mode, then you probably want to use the highest level model.
If you are in the implementation mode, then maybe a mid-tier model would be enough.
And for the reviews, then maybe a low-tier model would even be enough.
So things like that, we're actually looking at moving in exactly the same direction, I would say.
Thanks a lot.
Yeah, that's great.
Ich weiß, wie wir den Cloud-Default-Marketplace haben.
Ich weiß, wie fast sie mit Unternehmen oder Unternehmen oder Unternehmen, wie wir mit dem Geld haben, wie wir zu bauen.
Und ich bin auch sehr excited, um die Area zu sehen, wie ich mehr Lösungen auf hosting, Agentic Workload und sozusagen, die Harness-Sage-Service haben, die auch sehr interessant ist, weil wir uns sehr interessant sind.
Vielleicht nicht die differentiator we want to build for.
So maybe if we have a chance to buy security or buy that governance, it'll be quite helpful.
Yes, absolutely.
Thanks a lot.
So with that, I think we are nearing the end of the episode.
And towards the end, we always have some recurring segments.
One is actually the reality check where we ask our guests for WTF-Moments, die sie immer noch mit AI experience.
Ich denke, wir alle haben das immer wieder.
Aber auch, was die hottest Sachen ist jetzt.
Ich sage, wow, ich hätte nicht gedacht, dass das ist möglich.
So, do Sie haben die WTF- oder WTF-Moment?
WTF-Moment?
Ich denke...
There is still some degree of that.
It's like the speed at which we're producing documentation far exceeds the speed at which we consume documentation.
And that is why I emphasize a lot on the taste aspect, because it's almost like the documentation cannot catch up with reality.
Like there is just so much dog spinning around that is not producing value.
And it doesn't show to me sometimes that people have digested that content.
Und ich denke, das ist gefährlich, weil es ausserchen die Dinge zu den Agenten und die Menschheit nicht mehr Zeit hat, um das Kontext zu absorbieren und die Kontext zu digestieren.
Ich denke, es gibt noch diese WTF-Momenten hier und da, als ich diese AI-Generated Outputs habe.
Als für die WOW-Momenten...
So, like, as of today, I'm kind of exploring, like, the career framework and how to visualize that.
And it comes to me also as a realization.
Back then, I've also created an app to, you know, track that and show people's progress.
But with Cloud Artifact, it's so good, right?
And, like, building an app, like, to me, Cloud Artifact is building a generative UI, UX, right, that can satisfy.
The way you would want to present information.
I can make it editable.
I can make it presentable.
That gives me a lot of inspiration on how the next wave of product development should look like.
It's the way you would...
You don't have to build dashboards for people anymore.
It's like, say what you want and this is how I would visualize that for you.
So I love that.
I think this is a game changer.
Yes, I can relate to that.
So we are working.
mit einem Partner-Kompany zusammengebracht haben und sie haben auch noch ein paar Analyse von der Daten über Cloud Artifacts gemacht.
Und ja, es ist eine sehr interessante und sehr insight-generatinge approach für die Information.
All right, last but not least, do you have a prediction for our listeners?
Prediction.
Ich bin ein sehr pragmatischer Person.
Die Art, wie ich denke, ist, dass neue Dinge kommen, ich glaube, dass wir uns am Anfang an der Vorbereitung sind.
Das ist auch wie ich möchte, die Organisation zu führen, ist, dass die Leute die tooling und die Zeit, die lernen und die Dinge zu lernen und zu lernen.
Ich kann nicht sagen, ob wir noch ein Job haben in einem Jahr oder zwei.
Mein Meinung ist, Für mich, du willst, du willst, und du willst, auf der gewinnen Seite.
Ich denke, die engineers sind uniglich positioniert, um die besten tooling zu tun, um die Arbeit zu tun und um die Automation zu tun.
Ich möchte uns das Thema, um das Ziel zu sein, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden, um uns zu beenden careful worded prediction.
What is your prediction?
To be honest, we always have this discussion, right?
Prediction in the age of AI is especially hard since what I think Steve Yeggie said, that AI years are like dog years.
So it's seven times faster.
And that's why it's so hard to predict the future.
But I fully agree with you.
I think that what we currently see is a lot of the dass die Leute, die wenig wissen, über ein bestimmtes Thema, so die Dunning-Kruger-Effekt, sind wirklich beeindruckt, von den einen-schrittenenenen von AI.
Aber diejenigen, die eine deeper Erfahrung haben, will sehr schnell sehen die limitations der Output und werden dann beherentwickelt das sehr, sehr schnell.
Und das ist etwas, das wird...
I think for quite some time because the complexity of modern distributed applications grows exponentially if you just grow, right?
So you have different dimensions that you need to look at.
You need to look at the traffic that is coming in, the query patterns.
You need to look at the seasonality of load.
You need to look at the right technologies that you need to use.
You need to look at Wir müssen sich auf die Möglichkeit, wie man das in der Zukunft kann.
All of this, there are so many dimensions, wo man muss educated guesses über die Zukunft.
Für einen Engineer, der hat sich schon gemacht, ist es intuitiv.
Für einen LLM, der ist, dass es sich auswählen, wenn man es anewscht, und das kann nur aus dem Kontext, dass man es mit dem Request verwendet.
There's just limitations.
And I think the human will be needed for a long time, at least in the current architectural approach.
That doesn't mean, though, that a certain type of problems cannot be automated by LLMs or the combination of harnesses and LLMs potentially in the future, right?
So simple CRUD applications, that's probably not too hard, right?
If they need to scale to just a certain level of traffic or users, right?
Ja, es depends.
Es always depends.
Ich denke, dass ich das so, dass ich das so, wie ich glaube, dass die Taste ist wichtig und wie man weiß, wie es gut aussieht.
In der Endeffektiv, wenn Coding ist schneller, man muss sich nicht wissen, ob das gut genug ist für die Use Case.
Ich denke, mit Erfahrung, accumulating, wie Sie schon erwähnt, Sebastian, es hilft die Person zu kommen, wo wir schneller sind.
Ich glaube, dass wir uns mehr Zeit in die Zeit haben, um mehr Substanz zu haben, und mehr Bezügerung und mehr Kritiker auf den ersten Prinzip.
Ich denke, die Leute, die historisch gut sind, haben die Great Engineers, und das hat nicht verändert.
Die Tooling verändert, aber ich glaube, die Leute, die die Leute, die die Historisch bereits Great Engineers sind, sind die Great Engineers.
Das ist jetzt ein viel stärker und mehr positiveres Wichtig.
Danke viel Jenny, wir nehmen das.
Es war toll, dass Sie auf unserer Podcast haben.
Danke sehr.
Danke für die Folge.
Danke.
Bye-bye.
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.