Can AI Agents Safely Become DevOps Engineers?

It's a bit of a shortcut to
think AI non deterministic.

We need to be deterministic, so
we shouldn't use AI for that.

I think the right analogy is AI has the
ability to replace human beings on certain

tasks or help human beings augment them.

So it's not about replacing, everything
that people are doing, but in terms of,

of analogy, it's really about building
an agent that can behave and think and

act exactly like a human being would do.

So, for instance, your platform engineer
or your DevOps engineer, working for

you is actually non deterministic.

Humans are non

Humans are non deterministic.

Right.

This is the Agentic DevOps Podcast.

I'm your host, Bret Fisher, and today
I have my guest, Sam Alba of Mendral

on Sam goes way back, uh, one of the
early devs at Docker, co-founder of

Dagger, and now co-founder of Mendral.

So he's been focused on Cloud
native and now Agentic products

for 15 plus years at least.

And this is a wide ranging conversation.

We mostly focus on Mendral, the tool.

And the elevator pitch, I guess, that I
would give is, this tool currently looks

at GitHub, it's focused on GitHub Actions
right now, but GitHub as a platform,

particularly on actions and the workflows
and the events that happen there, but

not just actions and it tries to act like
a DevOps junior engineer essentially.

It's one, one of the closest, if not
the closest thing I have had as someone

who focuses on GitHub Actions and
CI in there and just administrating.

And managing that platform for DevOps
teams in particular, uh, it feels like

the closest thing to an AI buddy that
is constantly looking at my GitHub,

finding problems, not necessarily in the
code that the application developers are

making, but in everything else around it.

The linters, the testing infrastructure,
the GitHub action workflows and those

pipelines that are happening in there,
the logging events, uh, anything

misconfigured in security that dependabot
and renovate stuff, like just all the

stuff that is focused around the code.

For managing the platform for
storing code, running workflows

and automations on that code,
and then eventually shipping it.

They operate in this middle space
between the developers and the

production deployments in infrastructure.

And I think that's a sweet spot for me.

Like that's exactly what I
wanted to talk to Sam about.

And we spend quite some time digging
into the use cases for this thing.

I actually run through some of my own
experiences because I, they onboarded

me to the platform over a month ago, so
I've been using this thing irregularly,

but as a single operator of over a
hundred repos, now, in my own GitHub,

some of those are actual infrastructure
things in production for my own use, but

also a lot of examples for my courses,
a lot of demos and sample tools and

sample code that I'm have to manage.

I treat this like my operations, right?

So I'm doing the dependabot, I'm
doing the security reviews of things.

I'm automating things with GitHub Actions.

So while I'm not necessarily the
picturesque large team, managing

large, big projects on there, I do
operate my own little business of one.

I operate that in a very
similar fashion and I need help.

I need a lot more DevOps help than
I admit, because I need to operate

my business and I don't necessarily
have time to manage the platform

automation stuff around my code.

And that's really the problem I think
that Mendral's trying to go after.

So we break down what it does, what
they're doing as an early stage startup.

They just graduated YC.

And we then get into even more details
around AI and because they're building

today and they're graduating just
a few weeks ago from Y Combinator,

they are one of these new AI
companies that are building with AI.

They're using AI in the product
and their product ships AI

features to us as the users of it.

So they're kind of the
triple threat of AI.

So we lean into that a little bit,
talking about what they're using AI for,

what they see for the future of their
product, how do we going experience

these things in the future where we're
all operating our own AI harnesses

to manage our agents like Claude Code
and OpenCode and whatnot, when, how

do we use this tool in the future?

Anyway, we get into all that.

It's a great conversation.

I, I was excited to, to have it and we
went on so long that I, at some point

just had to say, okay, we we're gonna
have to stop talking and make this

another episode because we could have
gone for, uh, hours, I believe on this.

So please enjoy this episode
with Sam Alba of Mendral.

Welcome to the show.

Hi Bret.

Thanks for inviting me.

we started this new company, Mendrall.

We are now building an AI DevOps engineer.

we, we basically see that, you know,
the emergence of coding agents and

how they are shaping the, the future
of CI, CD and software delivery.

And so we're building an
agent that can unblock steam.

and now thanks to AI, we can
automate certain things that

we could not automate before.

And so today we have an agent that,
monitors and fixes, some of the,

software delivery issues, flaky tests,
slow build, broken release processes.

So, let's get into it because I,
so for, for the audience, Sam and

I talked, I don't know, a couple
months ago at least, I think.

and we had talked about Mendral.

I'm building GitHub Actions courses
and content, and I've been a GitHub

Actions consultant for probably
half a decade at least, or more.

I think, actions I argue is like the
most popular, certainly for open source,

but the most popular, CI platform.

I'm just kind of going to call it
automation platform from now on because

people do a lot more than just CI
in there and deployments and stuff.

Solomon had clued me in to you all
because we were staying in touch

around Dagger and, that's still going.

we started talking about your
focus and it felt like a tool,

that I should have in my toolbox.

it also felt like something where
typically with large platforms,

just like a cloud platform, like
AWS or Google Cloud, GitHub Actions

is a very raw platform to me.

I feel like it's got a lot of features.

It's got a lot of sharp edges.

But it also stops short of
what a, team typically needs

out of everything, automation.

And, we all talk about private
runners and we talk about sometimes

like custom dashboards or, you know,
org level statistics and awareness,

more, Observability into GitHub
Actions those are common questions.

and I don't often have
great stories for that.

because I think that market historically
where people have tried to have very niche

little products, but pre AI, that solved
a little pain point for GitHub Actions.

One, GitHub Actions wasn't quite
as popular five years ago, right?

It hadn't rose Jira and Travis
and a lot of the other ones.

And at the same time, there wasn't
the popularity, but these tools,

since they were pre AI, they were
very limited, I feel like, in

things that they could help with.

And so we saw, I saw personally little
companies starting out, like little

hobby products that almost felt like it.

They weren't true, they weren't YC
Combinator companies trying to come out

and be actually full fledged company.

They were more like side projects
and someone figured out, oh, I

could spin up runners faster.

Which is like a whole new segment of the
market where there's now many companies,

that host your runners for you, and
they're faster and cheaper and better.

And then we've had little companies
experiment with like GUIs or

web dashboards that do more than
what you might get out of the

basics of GitHub Actions there.

When we walked through yours,
was very excited about it.

because rarely on this podcast, after
we're about to hit 200 episodes of

this and the DevOps and Docker talk,
and rarely is there something there,

especially in the Kubernetes land,
that I feel like is meant for me.

That's something that solves my
problems, even as a solo developer

and as a consulting DevOps engineer.

So, could you talk a little bit
about like, when you both said, Hey,

look, we're going to start this whole
new company because we believe this

is the right time for this thing.

Like, Where was your headspace?

What problems were you trying to solve?

Yeah, so, is a really broad, area.

actually mentioned it.

not exactly for just running your test.

It's more like a workflow engine.

it's a lot about orchestration
and automation, and we

do a lot of things in CI.

CI was always a bottleneck.

every time, you know, you have
teams, as soon as you have some CIs

you start with some workflows, like
a linter, a builder on your GitHub

Actions or some other CI systems.

And CI is always a bottleneck because
first of all, it's a central place

for integration and for running
your tests when you ship your code.

When we started Dagger, we wanted
to help people with this bottleneck,

building programming tools so
engineers could actually solve

their CI issues more efficiently.

When we started, this new company,
Mendral, Andrew and I saw an opportunity

to finally automate certain things
that we could not automate before AI.

You know, for instance, there
are some release processes

that you need to run manually.

every team that's growing has
some sort of manual operations in

their, in their release process.

And on the other side, they have
issues that they don't spend time on

fixing because it's never the priority
you want to build your product.

You don't want to build your CI.

And the problem is these
problems are piling up.

That bottleneck is even getting bigger
with aI because now you have coding agents

that push a lot of code to your CI system.

And so the problem, this bottleneck that
was already a problem is getting worse.

And it's only the beginning.

And so we thought that now we have the
tools to, well now the problem is bigger

one side there is more demand for it.

And on the other side, we finally
have the tools thanks to AI to

solve these problems efficiently.

So the idea with Mendral is not
so much to make your CI better and

equip developers, it's actually to
replace that work, to automate that

work entirely so those developers
can focus on their applications.

So that's really TLDR
of why we started that.

And, and obviously software delivery
and CI CD in general is really broad.

There is security involved.

There is, you know, quality
control regression testing, like

a lot of things goes through CI.

And so we started initially
by building, we built an and a

data platform really, looks at

everything that's going on on your CI
system, the logs, the code changes,

the past incidents, all of the events,
the behavior of the team, like all

of this data, and then we started
to build specific agents on top.

That's really what we're
building with Mendral.

We have a lot of, you know, when
we started YC, we didn't know

exactly what we had a working
MVP, but we didn't know when, what

would be interesting for people.

We ended end up spending a lot
of time fixing flaky tests and,

you know, reliability problems.

We have some teams actually using the
agent to improve performance of their CI.

Like for instance, implement sharding,
strategies on top of their pipelines,

to have some parallelization and so
they can ship faster because the CI can

complete in a shorter amount of time.

There are also some teams
using us for security reasons.

Like for instance, our agent is
looking at security alerts, look at A

CVE, see if it's exploitable on your
code base, auto remediate if needed.

So there are really things
that you would expect a senior

DevOps engineer to do for you.

Uh, some of those teams actually
don't have specific roles for that.

So use the agent it's a person.

Yeah.

I think I've been in tech for 30 years,
20 of those years I've been dealing with

some sort of code management system.

And that doesn't always have an
automation system built, like we

didn't always have something like
GitHub where the automation system

and the code storage
system were the same thing.

but I'm just thinking back, and I don't
know a time where I would agree that

the CI or the automation system for code
was a first class citizen in the team.

It always feels like it's.

The, the, I don't know if this is an
American phrase, the, redheaded stepchild.

Like it always, yeah, it always felt
like it was just barely working.

And especially when it came to Jenkins,
we're not sure if we could exactly

get, we don't know how long it would
take to recover from a server failure.

Sometimes those servers
are under someone's desk.

Sometimes those servers are unique,
often, especially with Jenkins, not to

pick on it, but it was the most popular
and it was self hosted, so you always had

these special snowflakes of servers that
were built typically by developers, not

usually by ops, where the professional
sysadmins were operating, right.

Where they were the ones creating
systems to manage and control servers.

But often I would walk in and find the
dev team had their special CI thing and

it might be running on someone's machine.

It might be under the desk,
it might be in the closet.

And those days, I think because we're
pretty much all using at least some sort

of cloud API for managing our automation.

And we might have runners in different
places, but we're, leaning into more

cloud stuff, although it's amazing how
much I still see Jenkins and talk to

people that are still using Jenkins.

I often look at this as like, we have
needed tools like this for so long to

help clean up the, to me it's like the
janitor because while you're saying

you're building the DevOps engineer, I
know that every DevOps teams wish they

had another DevOps engineer to help them.

And feel like right now, at least
in this moment in AI, management

seems to think that they're going
to be reducing the number of DevOps

engineers not increasing them.

I just recently launched something
called the Agentic DevOps Guild

for people, personal plug.

But this is a membership program
where DevOps engineers are coming

in to help accelerate their AI
learning onboard AI tooling.

and I do these onboarding calls.

And so for the last three weeks I've
been having multiple, calls, with

engineers as they come onto the program.

And one theme that's maybe not a
majority yet, but it's a consistent

theme is, DevOps engineers are worried
of unreasonable expectations of their

management to do magic and they don't
even know these tools yet, right?

Tools like Mendral that run on
top of maybe an AI infrastructure,

they don't yet know Claude Code.

They're just dipping their
toes into copilot sometimes.

I think operators and DevOps engineers
are maybe a little bit behind

application software developers in
terms of their expectations to onboard,

development or coding tools for AI.

And of course, just six months ago I
was talking to people at KubeCon, that

were saying, well, we're never going to
put AI into infrastructure management

because that's a non deterministic
and we need full determinism.

And yet when I use your tool, which
feels like I don't actually know your

architecture, we'll get into that.

But it feels like there's
AI in the background.

I'm writing.

I'm editing plans for execution
with it in human language, right?

Like, I'm not checking boxes.

I'm talking, I feel like I'm writing
back I'm not literally chatting, but

I'm writing a plan, helping it edit
the plan so that it executes properly.

I'm writing, paragraphs of sort
of my rules for how it should do

certain things in infrastructure.

Um, so it feels very AI based even
though I'm not, I'm not, I'm not

literally chatting with the chatbot yet.

But at the same time, I feel like
we're, DevOps engineers are just in

this unfortunate situation right now.

We're getting hit from all sides.

We're expected to keep operating
our understaffed janitored, or

caretaked, infrastructure, right?

Our struggling infrastructure.

we're worried that we're going to
have less staff here pretty soon.

We haven't yet completely consumed all the
AI madness that the app developers have,

because we know that basically we're one
prompt away from production going down

because all we typically have the keys to
the kingdom, and a lot of teams have keys

that, you know, I was just talking to one
of the engineers onboarding that said,

I have the Terraform keys on my machine.

I have all the production AWS and
cube control keys on my machine.

I need to learn how to
sandbox this AI agent.

Or if it does one thing wrong,
I am I'm probably losing my job.

Right?

And that just feels much higher
stakes than an app developer that

got the wrong font on something
and has to recommit a new PR.

It just feels higher stakes for
all of us in the operations realm.

So that all being said, it feels
like you've kind of nailed it

without saying like too much of
a fan boy yet, but it feels like

you're solving a problem for me.

And so, for the audience, over the last
week, I've actually been working with the

team to try to get more of my problems
solved mean, I have over 100 repos.

Majority of those are training
repos or sample repos for learning

Docker, Kubernetes, GitHub Actions.

Like, so there's lots of sample
code, but it's app code, right?

There's lots of sample code GitHub
Actions, kubectl, like all sorts

of various infrastructure stuff.

I have an impossible time to keep,
like I cannot keep up with all of it.

I can't even keep up with the NPM
updates, much less, you know, CVE scans

failed, linting jobs, failed test runs.

There's just so much stuff that's
happening in the background.

I just, basically ignore it until
it becomes a problem for my students

or somebody bugs me in an, issue.

And I feel like finally with Mendral,
from a user's perspective, it's giving

me an opportunity to shortcut that.

It doesn't fully automate everything
for me yet, so I want to ask about

that, like where your vision's at.

But doesn't fully automate, doesn't
solve all my problems automatically.

It just feels like it's raising the stakes
of what's more important for me and not

to get distracted on the stupid stuff
that I might not need to worry about

because they're not really an issue.

They're just, you know, a failed
linting job isn't as important as

a failed test job, Um, so it's nice
that it elevates things that are

important and it also rolls things up.

it's like if you had this issue
a hundred times in a hundred

repos, maybe fix that one first.

And so where do you see all of this going?

If this thing is, you know, helping,
if it's giving intelligence and

insight, is what I feel like
it's doing to the failures that

I have in my automation platform?

Is this thing eventually
like learning from me?

And is it going to start solving
some of these automatically?

Like, where do you see that going?

Yeah.

So, yeah, it's an interesting question
and, is a lot to say about what you

said earlier about deterministic and
non deterministic and the use of AI,

pipelines that are deterministic actually.

and so.

Really briefly, I'll explain, just
for context, the, how Mendral is, is

behaving and how the product works.

And so usually teams, on board with a
single GitHub app install, one click

and then we start ingesting all the
CI logs and events on our platform.

And we basically run the agent in
such a way that the agent can see

everything that's going on on your CI.

It's like, it's like someone looking
at your logs, your events, your code

changes, everything that's going on and
looks for opportunity to be helpful.

you mentioned linter failing, that's
one, can be one of your pipeline

is slower by 30% percent this week.

And it was faster last week.

Why?

It can be GitHub is down,
like, uh, what's going on?

everything is broken.

The agent actually is able to
spot these kind of problems.

and and tell the team, don't worry,
the GitHub is down, it will come back.

It's not you.

Uh, they are, looking for many
opportunities to be helpful the problem

with most AI tools is that, You know,
people tell you, oh, it can do anything.

It's very powerful, but you still
have to find the right thing

that need to ask to the chatbot.

you know, One of the key, architecture
when we started to build the product was

that we didn't want to give yet another
dashboard, yet another chatbot to people.

And that's why it's an agent that joins
your Slack and start working for you

exactly like a human being would do.

One thing that's important to, to
keep in mind is it's not for me, it's

a bit of a shortcut to think AI non
deterministic, non deterministic.

And We need, we need to be deterministic,
so we shouldn't use AI for that.

I think the right analogy is AI has the
ability to replace human beings on certain

tasks or help human beings augment them.

We have some of our customers who already
have DevOps engineers and big platform

teams, and actually they have Mendral
joining that team and augmenting them.

So it's not about replacing, everything
that people are doing, but in terms of

analogy, it's really about building an
agent that can behave and think and act

exactly like a human being would do.

So, for instance, your platform engineer
or your DevOps engineer, working for

you is actually non deterministic.

Humans are non

Humans are non deterministic.

Right.

And the, output and the work
they do can be deterministic.

Like example of a linter,
like linter breaks.

We have to understand mistake,
what's the problem, why it broke.

All of that can be done by AI.

Then fixing the linter and pushing a
PR that can be totally deterministic.

Uh, so the way Mendral works today,
is we, didn't push the Cursor too

far in terms of automation because
we care a lot about security.

Like we have fairly large teams
using the agent in production.

And so we're very cautious about
the kind of, changes we make.

because the agent actually has
the capability to open PRs and

push code to people's repos.

And So what we do is the agent will
ask every time when it wants to do

something, it will ask for the permission.

So you have to confirm that yes,
you can go ahead implement that.

Yes, you can go ahead and do this or that.

Over time we have people asking us more
and more to actually automate more.

So if the level of confidence of the agent
is greater than, let's say 85%, percent, I

want a PR to be open automatically.

because actually have a pretty
high merge rate from the pull

request that module opens the pull
requests that are accepted by teams.

And the reason for that is because
we have fairly long coding session.

So when the agent implements
something, it's fairly similar to

what you Claude Code or Cursor.

But the main difference is that it
will wait for the CI to complete,

wait for the logs, to show up and
actually wait for the confirmation

it actually fixed the problem.

So if it's fixing your linter, it
will wait to confirm the agent itself,

will wait to get the confirmation
that the problem was solved before

saying, yes, okay, my PR is ready.

Exactly like a human
being would do, right.

And so, that's the main thing.

but yeah, over time, like we're
going to push for more automation

and we're going to do a lot more.

you asked also about the,
um, the, learning phase.

That one is actually very interesting.

I don't know if you want to react
to what I just said, or if I should

expand on the learning aspect.

Yeah, let's talk about the learning.

So on the learning side,
what's very important exactly.

Like when someone joins your team,
the person doesn't have context.

So you start by watching the team, joining
the team, making themselves useful, right?

but then over time, the person
will knowledge a lot of things.

problems, the tools, the best practices,
and then it will get better and better.

Same thing with the agent.

So the agent, when it sees something,
that needs to be remediated or it sees

problems, it can identify patterns and
maintain a list of what we call insights.

They are basically opportunities for
the agent to do something can be a

failure, can be a performance regression,
security alerts, etc. All of that

is being tracked by the agent and
constantly being refreshed with new data.

That's why, for instance, if it spots
a problem the first time, the level of

confidence on the resolution might be low.

And then as problem appears several
times, level of confidence will

get higher to the point that we can
entirely automate the resolution.

And that happens based on, the agent
being able to, to constantly update

this living memory and taking that
into account whenever it is a problem.

So when it sees the problem, it
doesn't just look at the problem in

the logs, it sees at all the context
of the problems that happened before.

It has the ability to look at, you
know, similar issues or similar

patterns that he saw in the past.

And I can dig into the implementation
of that because it's actually

quite interesting how we architect
architected this, this agent.

But then also team sometimes talk
to the agent on Slack and say, oh,

whoa, whoa, whoa, you did that,
but we actually don't do that.

Like let's say, you know, we,
always follow that benchmark, so we

always use this tool or we always
do this, and basically people react

to the agent and say, Hey you keep
in mind we do this and not that.

And the agent also has a memory
system and maintains its memory.

You can also review the memories
and edit them, et cetera.

But yeah, the idea is to make that
learning part entirely automated so the

team doesn't have to care about what
the agent knows and what it does not.

and so that's really the key part,
about the non deterministic way.

I think the right way to frame it
is really think about what a human

would do and think about the fact
that an LLM can resonate and navigate

through our problems in the same way.

you and so that's really what makes this
kind of automation possible today it

was not before LLMs were good enough.

Yeah, and it's subtle.

The more I feel like we're spending
leaning into just trying to use AI

in various scenarios, the more I feel
like my mind expands to understand

where it actually could apply to
things that I didn't even think about.

Like I feel like to me, Mendral,
the premise to a, to a non AI,

what I would call a blue pillar.

keep a blue pill and red pill
matrix, 25 year old dated reference.

but the blue pill people would be the
ones who were not necessarily anti AI,

but very, you know, very much not pro AI.

They're not leaning in hard, they're
like, yeah, yeah, it might help me

with my code completion, but I'm
not looking to put AI everywhere.

And that's fine, there's people like that.

And then there's the red pillars,
and I used to consider myself the

blue, and now I'm basically all red
and looking for new opportunities.

In this use case where we're saying,
okay, yeah, it's going to be helpful in

CI at first when, you have this three or
four years of experience of hallucinating

agents and things going crazy.

That sounds like a wild premise.

But what I find is interesting, and
I'm using this also in my own work with

things like Claude Code and OpenCode
and learning how skills and other,

other new tools all patterns that us
humans are using to help guide the

AI, give it more context, give it more
guardrails so that it won't hallucinate.

And we, like you said, we get to
like the 85% percent trust level,

you know, we get to this certain
level of trust, particularly

with a certain model or a certain
harness, and then we start to relax.

And I've noticed recently, like even
my prompts are getting sloppier.

Like, I'm not prompt
engineering anymore, right?

Where we were consumed with that a year
ago, where you got to have the best

prompt, the only way you're going to get
a good, reliable AI is the best prompt.

And you go to these websites and they
have all these listed prompts, and now

I'm just like, Hey, can you fix that?

I'm very vague, I'm very casual
like I would to an employee.

But for me, I know that, that one,
that's because I've, I'm consistently

using skills, which are these large
documents full of context, and that

I'm operating on larger and larger,
whether we want to call it context

or memory or sessions, whatever.

In the AIs, I'm constantly Continue to
use the same session, which it compresses

and I expand it and it compresses.

what I'm finding in my AI conversations
as I'm able to stick with the same

conversation, the same session much
longer because now we have Claude

Code with million token context now.

And that just unlocks, I feel like for me,
I mean, yes, I'm using more tokens because

I'm in the same session, so I'm not a
Ralph Loop, fanatic where I'm constantly

dumping context and starting fresh.

But I find that I'm actually able to
have these conversations that extend for

more than a few days, but into weeks.

And it remembers the thing
that I told it two weeks ago.

And that's where it starts, I think,
to get really, really interesting.

And that feels a little bit like what
I'm playing around with, with Mendral,

I wanted to call out one feature that I
just started playing with a couple days

ago and this very specific problem of,
we've got so much, what's, the term we use

for teams, that have all the canon inside
their brains and it's not documented.

I'm trying to think what that,

It's tribal knowledge.

Tribal knowledge.

Okay.

So, a while ago, and I love that
term, tribal knowledge, like

these are the things that you
onboard that new DevOps engineer

And they're, they're not
going to just read docs.

they're going to make mistakes.

And then a team member is going to say,
oh, no, no, no, we don't do it like that.

This is what we do.

I ran into that where it wasn't
documented in any of my agent files yet.

It wasn't anywhere in code or, documented
that when I run superlinter, particularly

against GitHub Actions, because since
I'm teaching GitHub Actions consulting

GitHub Actions, I'm all into that.

and I've always been very concerned
with the security side of it.

And now that we've had a rough year,
GitHub Actions has had a rough year.

This last year has not
been kind to, to me.

the GitHub team in terms
of security attacks.

I'm not even going to
call them vulnerabilities.

I'm just going to call them sharp edges
and misconfigurations a lot of times.

because it turns out
they're not hacking GitHub.

They're just finding people
that didn't configure things

correctly on an open source repo.

And this is all happening.

So I'm always scanning my GitHub Actions.

I use actionlint and I use
something called Zizmore, I

think that's how you say it.

Zizmore is Zizmore.

Um, And Zizmore is very
focused on security stuff.

And so down this rabbit hole, I'm going
to go with you for a second, but what

was happening was they added a new rule
to the linter that says, from now on

you need all of your actions need to be
pinned, Which for those of you out there,

if you're using GitHub Actions, hey, if
you don't know about pinning, I've got

a bunch of videos and courses on that.

Like, you absolutely should
be pinning all your actions.

And rightfully so, now, the linter warns
me that I'm not, when I'm not doing it.

And in reusable workflows, there is a
pattern that surfaces with teams where

if they're controlling the reusable
workflow, they don't tend to pin to the

SHA hash from their calling workflows
because they control everything

centrally from the reusable workflow.

And that's the point of them is to
centrally control things so that

we don't have a hundred different
repos that I have to update every

time a different workload changes.

And so this security tool doesn't
know that, Mendral doesn't know

that that is not documented
anywhere in any of my systems.

It's not in my notion,
it's not in my repos.

So that's tribal knowledge.

And what I was able to do is it was
flagging a bunch of these things and

saying, Hey, Mendral, Mendral was thinking
the fix to this is that it needs to

pin the SHA, but in my team of one, the
real fix is no, we need to just write

an ignore rule for the Zyzmor linter.

And that's very specific to
my workflow, not something

that other people would know.

And so I could give, instead of making
that documented somewhere and then

somehow connecting some MCP and some
convoluted way to let Mendral know it

has this memory feature where I can just
sort of dump in this tribal knowledge

in just copy and paste or writing in
stories, basically user stories that

helps it guide the decision of how it's
going to treat future failures, because

what was the outcome was happening, and
sorry for the audience, this is a really

long story, but I feel like it's very
tactical and relevant as an example.

Is, in that scenario, if I had a junior
engineer, I would say, okay, please write

all, we're going to need to update all
of these calling workflows with a hundred

repos now need this new line inside of
the GitHub action for this particular

calling workflow that calls a reusable.

And then from now on, everyone in
the team needs to know we don't

shop in on our calling re workflows,
we only shop in on the Reusables.

And with Mendral.

I was able to put in one memory and I
haven't seen the outcome yet, but I'm

gonna ask you in theory, I guess that
means that from now on, every time

Mendral sees this error, its new PR plan.

That it's going to give me, isn't
going to say, Hey, I'm just going

to replace this with a SHA hash.

It's going to say, oh, I'm
going to put in a new rule.

I'm going to basically ignore this in the
Zyzmor linter so that we don't, we know

that this is okay and we don't flag it.

Is that kind of the
expected outcome of that?

Yeah, that's right.

there, are many ways you can influence,
the behaviors of the agent today.

And yes, indeed you can
actually create a memory.

It makes sense when there is
a pattern that you want to be

widespread and apply everywhere.

the sticky note that you want to
put on the deck of your engineer.

That you want to make
sure is never forgotten.

Another thing you can do is, for
instance, let's say you want to

migrate or to implement, some sort.

of, let's say you have this new linter
that you want to migrate from an old

one, or you want to implement a new
security tool or something like that.

So, the outcome will be deterministic,
but asking that will be certain, more,

likely done in a non deterministic way.

maybe there are some
things that you don't know.

Like for instance, the agent has the
ability to do a web search or like look

into best practices or things like that.

And so what you can do is also ask
the agent, Hey, this is my plan.

This is what I noticed and this is a
problem for me, I'd like to address it.

The agent will actually create an
insight for it and track it, and

propose an implementation when the
level of confidence is high enough.

And and yeah, it has also the
ability to, update, findings.

So sometimes the agent, you know,
you talk about tribal knowledge.

There is also some of the tribal
knowledge and our own experience,

as as engineer with Andrea,
Olivier into The agent itself.

So we constantly change the way we, you
know, Mendral does stuff, and that's why

it feels magical sometimes when people
on board with it, because the, what they

actually don't realize is the agent has
our own experiences hardcoded in, in

some of the subagent that we, we wrote.

And so you can actually,
influence that too.

And the agent has the ability to update
its own insights based on your input.

So if there are certain things
you disagree with, because let's

say, you know, if you would hire
me as a DevOps engineer, I have

certain things I would like to do.

And you're like, well, no, actually,
Sam, I'm paying you, so I need

you to do it this way instead.

can ask Mendral the same
thing, and it will be fine.

So yeah, the, customizability is
important because that's the kind

of control you need from someone
you would hire as well, right?

You expect this person to bring
their experience, but also you

have your own requirements.

so so yeah, that's, that's
something we constantly, improve

and, make available to, teams.

Yeah.

And that's the kind of thing where, mean,
testing tools have this problem, linting

tools have this problem, really any tool.

But I think like those are the two
areas where, maybe the linters might

be the worst, where when something
new is added, a new rule to a linter.

uh, I, think I had another
tool recently, actually.

Well, that was, that was a NeoVim tool

Okay.

It's like everybody's refactoring
all their apps now with AI.

So it broke a lot of things and
I spent an hour on it and AI was

able to solve it so much faster.

So, but not so not related.

That was just something
that happened yesterday.

Because I mean, the stories, if someone's
like in the trenches as a DevOps engineer,

that scenario that gave, while it's just
a linter, not inherently high stakes,

I it wasn't a testing failure or a
production deployment failure or anything.

But that's the kind of thing when I work
with DevOps teams, that's the toil, right?

That's the thing that they don't want
to have to go change literally a hundred

repos of microservices and back end
things because they've implemented

some sort of central reusable workflow.

But now the crux of all that is
they have this thing everywhere

and something breaks, and now
they don't have the tooling.

To update.

They basically end up spending days
writing scripts to create the PRs in

100 different repos to fix and then,
automate the creation of the commit,

creation of the PR, the acceptance of
the PR, and then the merging of the PR.

Because they don't want to literally
spend 3 or 4 days just mindlessly

clicking through 100 repos to do this.

And I've lost count of how many times
I've watched teams go through this

toil of, like, your week is going to
be fixing a stupid linter rule across

50 to 100 repos because the, dev
teams don't want to do it or whatever.

Or it's now our job to do it for
some reason, even though we're

not the application engineers.

Sometimes I have worked with teams
where it's the DevOps engineers

literally implementing the linting
rules for the software engineers.

I don't know why that happens,
but, sometimes we get saddled

with work that's not ours.

But that automation part,
I feel like is another.

it's almost like a hidden feature that
talk about raising issues, we talk about,

helping understand the nuance of things
and the patterns that you're seeing

so that it can be more intelligent.

But at the very end of this really is
all about, to me, saving the toil of

manually checking repos for things.

Because, constantly struggling
with workflow failures that

aren't rising to the top.

Because when you have a big
enough team, you've always got

workflows running, you're just
constantly inundated with workflows.

And the challenges is the alert fatigue
in Slack or whatever tool you're

using because you're, working with.

just can't keep up.

So you start to say, okay, well now
we're linterfailures, we're no longer

alert in Slack, so now we're going
to just remove those from Slack.

We're too busy to do that now.

We're only going to deal with
deployment failures or only testing

failures on these particular repos.

Like you end up having to force
yourself to ignore a whole series

of problems because you just can't
handle, there's just too much work.

And to me, the more exciting thing
is that I might be able, you know,

and maybe someday I don't know if it
does it today, if it would be able

to go and simply apply a hundred PRs
for that particular calling workflow.

because I name it the
same thing everywhere.

But my hope is that someday, if not
today, like that would be able to get

automated so that I could just be done
like basically a hundred PRs later,

it's taken 30 minutes or something.

I didn't have to write a script,
I didn't have to worry about

nuking or breaking some repos
because I wrote the wrong script.

I can, give that to Mendral,
which is exciting for me.

Yeah, I can tell you more actually
about, about that, because there

are a lot of things we're working
on today actually that some of

it actually might be available by
the time this podcast is out, so,

okay.

yeah, we're working, yeah.

quite, fast on these things because
there is a lot of demand for it, you

know, as soon as people onboarded the
agents and they see the value that it

can unblock thanks to the data layer
and, the, which usually we refer to

with the agent harness, which is kind
of the combination of the tools and the

context and the way we build that and
keep the agent accurate at any given

time, actually, this really the key.

But yeah, in terms of what works today,
so the agent is not stuck with one repo.

Sometimes in CI, when you have,
you use products, you realize

that repo maps to a project that
could sometimes map to a team.

Some companies do it this way.

And the issue is, well, it's great
when you have, you know, that

mapping is great and works fine and
you're okay with those boundaries.

Problem is, most teams are not,
and sometimes having a repo is

just an implementation detail.

And exactly like you said, you want to
think about something you would apply

to all of your repos, all of your codes.

need to think about this repo
behave like this or like that,

etc. TLDR is, Mendral has been
designed, so it's not tied to a repo.

It's actually tied to
an organization today.

uh, that's, that has been
designed one or many repos.

We have teams with like a
gigantic monorepo and that's fine.

And usually what they do is
they have this mapping inside

folders and sub directories.

and then you have some teams who have lots
of repos actually, and there is no mapping

whatsoever from a team or role to a repo.

And Mendral doesn't care.

Like insights can be
applied to many repos.

One thing that we were working on
that that's actually I'm very excited

about is, so we have this data that
comes and that knowledge and the agent

running based on events and teams
asking for stuff and things appearing

and background tasks and all of that.

And so the agent constantly working for
you and constantly looking at its data.

We are building the ability for
you to have your own agents on top.

So basically you will have a
simple way to define your own

sub agent on top of Mendral.

And so it will really feel like
you're giving, some specific

instruction, like almost a mission
to Mendral behind the scene.

In terms of architecture,
it's actually a real agent.

It's like a real agent that's
linked to everything else.

And it's a sub agent that will
be called by main Mendral agent

whenever it needs to be called.

And so you'll have the ability to say
whenever, there is a code change or

whenever, like, we'll actually add
mapping to other sources of data.

it could be whenever there is new
exception on Sentry, for instance,

because we are actually expanding
beyond the CI logs also, I want to do

X, YRZ, want to do this, and I want
to be notified on Slack or not, you

know, because I don't want the noise.

So you'll have the ability to build
your own, so I call that agent because

it's de facto like a real agent.

Some people might call that like
agentic workflows or something,

but it really depends what
will be your use case.

but yeah, we want to, you know, I realized
that It's actually a dream to onboard

an agent that is doing work for you.

and that dream is true today,
actually, saying that in, you know, not

overselling the thing, but that works.

That said, every team
has a unique CI, right?

every time you have a unique set of
tools, unique set of, best practices,

you are using several external
services and infrastructure, data

that you are managing somewhere.

And so all of that is unique to a team.

And you cannot have an agent that
will figure this out entirely.

And so we're gonna make the ability
to plug those data and this,

this integration into the agent.

So it can actually Work in a
more, specific way to your needs.

so that's really what
we are building today.

And there is a lot of demand for it.

Um, actually two things.

There is a lot of demand
for customization.

and plugging to other data
sources and other workflows.

And there is another demand
for, having more automation.

So

it's very interesting to me to see,
and you said it well earlier, is.

it's interesting to me to see that, people
actually trust AI tools a lot today.

Like some people ask us like, can
you actually for, some of those

problems, like automatically
open and merge the pull requests?

And like, well, you know, it's going fast,

So, so

Well, that's the,

talk.

we'd get there.

Yep.

the trust, right?

Like if you had, like on the, on
the live stream, we had a couple

weeks ago I was talking about that
I don't remember the last time.

My coding agent locally.

and that use, I use Opus, I
use sonnet, basically any state

of the art model I use GPT 5.

4. I have all the subscriptions.

I don't remember the last
time I would have classified

it as a true hallucination.

it has been months.

Right now it gets things wrong,
but it's usually because I was

lazy and didn't give it context.

Right.

it just made the wrong choice
because it acted like its first week

as being the engineer on my team.

And I blame myself for that, right?

it's a me not you problem.

And so that has definitely, for me, I
have certainly established more trust.

Like I might be at that 85% percent
level like keep talking about.

And if I did this in CI,
if I was using Mendral.

and, you know, I don't technically I
don't have to know what agent, what models

you're using on the back end, right?

Like, I just know this thing is
able to give me plans reliably that

I agree with, and it gives me this
implementation plan to fix a problem.

And I go, yep, that sounds
like it's great, a great plan.

That's exactly what I would see in
a PR from a junior engineer while

I'm reviewing it, right, I just
happen to be reviewing this pre

pull request, implementation plan.

And if I did that a hundred times
over the first couple of months of

onboarding a tool and I never saw, or,
you know, almost rarely ever saw anything

wrong and those wrong things weren't.

That wrong, they were
just maybe a preference.

I would absolutely be more trustworthy.

And I can imagine myself right now in
a team where if I'm onboarding uh, an

orchestration agent engine like Mendral,
where I'm going to tell the team, okay,

they have this new automation feature
that they've just launched so that we

can fully allow the AI to make the PRs
and then commit them automatically.

And maybe it's two different
models with two different contexts.

That one makes it, another one reviews it.

Right?

We've been discussing lately about
how, like, when are we all going

to be comfortable with the AI
writing the software, and then the

different AI reviewing the software?

And does it need to be a different model?

Does it need a different system prompt?

Like, you know, these are questions
that are coming up actually

within uh, the guild meetings
that we are having every week.

And I can see myself very quickly
saying, well, we're going to allow

it to auto merge any linting failure.

Because it hasn't been wrong
in its implementation plan in

two months or whatever, right.

And we're going to tiptoe in with low
stakes stuff and then, you know, maybe

we can make a rule where Dependabot, this
is another big pain point for me, right?

When you have dozens and dozens of
repos and Dependabot, or renovate

comes out with a minor update.

And typically, it's, a wonderful life if
you're in a monorepo right now, because

if you're in a bunch of microservice
repos, you just have sprawl of repos, you

know, one JavaScript dependency module
update, and suddenly you have 20 PRs

to approve and they're all the same PR.

So they're, and I don't believe
that Dependabot has a, just do this

for me in all 20 repo mode, right?

it doesn't automate that process.

So then I'm literally going through
and clicking, I think I'm probably

at the point of comfortable with
my local AI saying, Hey, just

use the GitHub command line tool
and look through all of my repos.

this would be a very long prompt, but
look through all my repos for this one

particular Dependabot for updating.

It's got this exact title because
they're all going to have the same title.

And if you see that in there, go
ahead and accept it and merge it

with the GitHub command line tool.

I do think I'm at that level, but,
so if I'm at that level, and I'm not

even the most aggressive AI person
I know, like I'm not even, I haven't

even installed OpenClaw, right?

I haven't installed any of these
crazy, orchestration engines.

I'm sure that there's lots of people
that are absolutely comfortable with

this and I'm, I am all about this
because there has never been a good

time to tell the story of DevOps
automation platforms as a thing that I

can implement in a reasonable amount of
time for a reasonable amount of money.

everyone that I know that's
struggling with this, you

know, don't want to entirely.

invested in a proprietary tool sometimes
and they want to open source everything

themselves, which is the tough road ahead
for anyone that's trying to do that.

because I'm doing this in my courses
where I'm trying to explain how

to do all these AI workflows that
help you do a lot of automation.

And I can tell you that tools like
Mendral are the easy button versus

trying to do it yourself with a bunch
of more workflows that all do the

things that Mendral's already doing.

But this is, there's, you know, we've
had all these different automation

engines over years that have tried to
become a market dominant force for just

easing the toil on DevOps engineers.

And I never feel like
anyone's really cracked it.

I don't go into any shop and find that
they're all consistently, or a majority

of them even are using one tool beyond
GitHub Actions to automate things.

And very rarely do I see
people with GitHub Actions.

Only the, like most mature teams that
I see in GitHub Actions are doing

things where they might have like a
central repository of actions that

are aggressively doing things on other
repos in an automated way, like checking

the security settings across all my
org repos in order to make sure that

we're not exposing a security risk
by allowing, you know, forked pull

requests to automatically run actions,
for example, which is one that's really

biting people in the foot right now.

Like that thing needs to be locked down
on every repo, and there's no tool built

in to tell you what that setting is, so
you have to literally either hand code

something check it yourself or create
actions that do all this automation.

And it feels like we're right at the
cusp of just, I just write a, either

a skill for this or I have a tool
that automatically does this for me.

I do like this agent idea because I
would like to put in like a DevSecOps.

That's the next one for me where I
wanted to go and actually like, look

at these org and repo settings and
report them, port back when it finds

one that's not set properly for me.

Maybe something that I don't want
to be a linter, but I want it to be,

you know, security checks on my repos
and on GitHub itself that an engineer

doesn't want to have to run that script
manually every day and then do all the

work of fixing the things every day.

I'd rather just an AI do that,
'cause it's a binary thing.

It's like either this setting's
checked or it's not, and if it's

not checked, you need to check it.

This is a very

basic thing.

Yeah.

there are a lot of things like that.

Like for instance, when you start,
putting together some compliance

like, you know, soc 2, for instance.

there are a lot of controls that, you
start implementing that very important

and sometimes time consuming as well.

Like you need to have a human
checking that constantly or regularly.

and so yeah, this
compliance is another thing.

And security in general, is something
that uh, we think we can help with.

you mentioned Dependabot and the noise
that it causes and, we had some early

prototypes of having some rules that are,
when some rules are met, actually the, I

don't even want to know about the PR and
I just like merge the thing and so so we

if it's a point release, yeah, if
it's a patch release, just do it.

Just do it.

Yeah.

Yeah, especially the build
works like the CI passes, like

I don't want to deal with that.

And so yeah, we had some prototypes
where we automated entirely

some of those, use cases yeah.

And I think they, from the feedback
we're getting from our customers,

people are getting there actually,
um, they are getting ready and

so, yeah, it's very interesting.

And think very soon you'll
have the ability implement

your own DevSecOps agent.

we're going to keep adding
more agents ourselves too,

because magic, plug and play.

like it when you're on board because you
don't have a lot of time evaluate another

tool so you prefer to onboard it, it run
on the side and see if it's valuable.

And then if it's valuable you want
invest more in it, which means

defining your own agents, and then
on top of that, we do orchestration

on top of this fleet of agents.

so they are called at the right
time with the right context.

You mentioned something
also about hallucination.

I think it's very interesting because
I think you're right that LLMs got

better recently in the last few months.

And, they're definitely a lot more
powerful in term of how they think

and the kind of mistakes they make.

we actually built a lot of, engineering
around the LLM to deal with this.

And so we realized that, you know, the
era of the rag is kind of over now.

Like you don't need to pull like
an entire context and try to guide

every single thing that the LM
should do, or, or should consider.

Instead, the prompts are getting
smaller and you put a lot more

intelligence in the tools themselves.

and what I mean by intelligence is, for
instance, in the case of Mendral, we

do static analysis on the tool calls.

And so we are able at runtime when
the agent calls some tools to detect

some drift from initial mission.

and we, nice thing is you can, you have
the ability when you do that correctly,

with result of the tool call to actually
influence the thinking of the agent.

So it's almost like Yeah.

That's great.

the agent starts somewhere and
starts doing something, and then at

some point he goes on the side on
something, you know, useless calling

comments or, you know, some things
that are not actually very useful.

You can actually steer it back to plan.

And so we spot those things
in the tool calls and say, no,

no, actually don't do that.

Do this instead.

So for the agent, it's like I'm calling
a tool, and it's weird because the tool

is telling me to do something else.

So that's really works.

But the nice thing at the end is that
you, have almost a dynamic prompt.

So instead of having like very long
prompt that you pass initially.

You let the agent pull the context,
and from that context, you can actually

dynamically change that prompt at runtime.

And that's really what
gave us best results.

coupling that with sub agents,
it's actually very important.

Claude Code is doing that really well too.

Like when it

explores codebase, it's doing
that in a sub agent because

you don't need the whole thing.

All context of the exploration
back into the main loop.

You don't need that once you got the
results, you want just that result to be

in the cause of your LLMs moving forward.

And so that's also what we do.

And so so yeah.

It's very interesting to see that like
those patterns being LLMs getting better.

I think all of that is getting
closer and closer to, the kind of

work that a human could do For you.

And so, yeah, that's really
what motivated us to start this

company in the first place.

Because you can sort of foresee, I can
imagine that you can foresee like these

things are getting better at a steady
pace and it's not just the models that are

getting better, we're understanding better
how to, you know, because we don't just.

you know, taking a blind model and
putting it into a random situation

where you need to have it write code.

it's like, to me it was like bringing
a kid to school straight out of

university who just learned how to
program in that language and sitting

in the chair on day one and saying,
okay, now, write me some code.

Commit it to the do all these
things without any context, right?

We just didn't understand
that we needed context.

And of course we had smaller context
windows, so that was also a struggle.

But like for me recently, I use OpenCode
a lot more than Claude Code now.

every time I keep trying to go back
to Claude Code, even though it's

got some really cool things that
there's not yet in OpenCode, they're

back and forth It's my two favorite.

And I talk about this a lot, I
think I probably mention it on

every show nowadays because I'm
just obsessed with it all day long.

But started to integrate LSPs, which I
think is leveling up code accuracy the,

we don't really see it happening, but
just feel like my OpenCode, because LSPs

are in there out of the box we're with
the Claude Code, I think you have to

actually add the extensions manually.

where OpenCode dynamically injects it
when it sees a language in real time.

And I just feel like OpenCode
for me is a little bit better.

And I don't have a way to prove this
theory, but I think it's maybe because of

that LSP background where it's constantly
helping tools, helping keep it on the

rails essentially, of how it's writing.

And this is all I feel like leading
us to what some of the experts out

there for the last year, over a year
really, I think last year I saw a great

talk from the president of, I think
it was Gradle, talking about not only

is AI coming for DevOps and operations
because it just has to, because the

software development lifecYCle can't
be optimized for agentic coding without

the rest of the pipeline also improving.

if we're going to improve 2x,
the entire pipeline, the entire

lifecYCle has to be improved, 2x.

We can't just have developers tripling
their PR rate and then the rest of

us all act like nothing's changed.

we're going to have to accelerate,
we're going to have to use AI as well to

accelerate, unless we're suddenly going
to double the number of ops people, which

nobody, I don't see any teams doing that.

they're going to have to use AI.

And in that premise, if we're possibly
at this moment in time, if we consider

these more junior engineers, not so
much senior engineers in terms of their

overall intelligence and accuracy.

If that's the case, then we're going to
need better guardrails, we're going to

need more testing and, you more rules
and more guidelines for them to follow.

And then we're also going
to need to remediate faster.

A lot of times when people talk about
remediation of failures or recovery from

failures, at least in like the Kubernetes
world that I live, a lot of people

are talking about that from just being
able to detect failures in production.

Where I live is more in the CI world, and
that remediation is more important to me.

And I feel like that hasn't
been clearly unlocked.

And it feels like tools like Mendral
are way forward in that regard in

terms of they're going to help me
recover from failures faster so that

I can, you know, this is all in Git.

like we were this entire
conversation is talking about Git.

GIT is protocol that
allows me to undo mistakes.

So if we're so apprehensive and we
sometimes in DevOps, especially in

ops, we get so apprehensive about
change and we're constantly fighting

our one side of our brain wants to
not change anything because it works

right now and we're just fine with it.

The other half of our brain's like,
this is all needs to be better.

It could be so much better.

Let me fix things, let me improve things.

And that tension is just
naturally in our brains.

And this feels like a
way for me to go faster.

Also, understanding that maybe it's
not going to get it correct 100 percent

of the time, when it fails, it's
also going to elevate the failures.

It's also going to find the failures
and fix them faster so I could go faster

if that means, well, that outage might
be 10 minutes on that test failure.

we broke a test, we fixed it
within 15, 20 minutes, nobody

even noticed, we're all fine.

So what's the real risk here, if
this thing is really just committing

PRs against my infrastructure,
it doesn't feel like a huge risk

because I'm not having git repo.

Right.

at least that's how I take it.

is the stakes are actually a
little lower because I'm in git.

thing you said actually that's very
interesting is, just about going faster.

I, heard people telling me that
the production of code has been

solved it's going to be fine.

And I think it's about to be solved,
honestly, using a lot of AI ourselves.

But I think there are some physics that,
are ruling the world that are not going to

change, which means, you can write a lot
of code in parallel, but at a given time,

there is only one version of your code
that goes to production at a given time.

And so you, you always need
that no matter what happens.

and I'm sure the software
delivery is going to change.

We're going to participate to that change.

It has to change, that's for sure.

Like when you even just a detail.

But when you look at how PRs
are being reviewed today?

Like, realize that maybe
it's not the right, paradigm.

be done differently or possibly
with different tools actually,

But in any way the

to do human q a, by the way, Q, not Q,

A, QA, like we used to do human qa.

Now, if you're doing human
qa, your legacy, like if

you, yeah, this could happen,

you still need to do, it's actually a
very good example because you right?

it's automated you still need to do it.

And I think the same thing happens
with, software delivery at a given time.

You need an integration loop that's
going to make sure that you can

actually ship the one single version
of your software at a given time.

you don't have this constraint when you
publish code thanks to Git, actually,

and you know, you can open any branch,
any PR, anything, but you still need

to integrate them at some point.

And I think that that's going to stay.

and so even though all the processes
and the way people work is going to

be different, but, yeah, no, so that's
actually very interesting, to hear

in terms of going faster and what are
all the things needed to go faster.

It's not just about writing code.

Let me ask you real quick
on a very specific subject.

our friend Victor Farcic, you might
know him, DockerCaptain alumni and,

YouTuber, who has been doing a lot
of AI videos over the last year.

We had a conversation recently where
he believes, and I totally agree with

this statement, that the harness, our
local harness, whether that's Claude

Code or OpenCode or Copilot and VS
Code or however you want to roll, That,

that's going to be the way that not just
devs, but maybe DevOps and operators

and platform engineers and SREs.

This is going to be like our window to
the world, and the more we can stuff

context into it, the more we can give it.

learned yesterday from another DevOps
engineer that's making his own, he

has his own skills, essentially.

He's not using skills for this particular
thing yet, but he's creating a me skill

and that's how I this, and I'm going
to practice this in the next week and

see if it helps there's a rising theory
that we shouldn't be telling the AI.

Hey, you need to be an expert marketer.

You need to be in this role,
you need to be an expert SRE.

But it's more important that we tell it
about us and what, how we work and what

we expect, rather than tell it what it is.

And so one of these engineers in the guild
was saying that he's had a lot better

output of his LLM by describing himself.

And he, I think, I think he injects it
as a command or something in his harness.

I see of that as more of a skill
that I just need to flood into each

conversation at some point so that every
session, the AI knows more about me

and my role and how I want to operate.

And so getting back to Viktor, Viktor
feels like this harness that eventually

will know us personally better.

It will have maybe it's
more docs from the team.

It'll have more access to.

confluence or Jira or Notion or
whatever you might have that gives

it more context about environment.

So thus, that seems to be the best
way forward for interacting with all

of our systems, not just our code.

This the theory he has.

I think this feels like a
pattern a thing that I want.

Do you see Mendral as being
something rather than in Slack

what is the primary chat interface?

You know, obviously there's
this great dashboard.

Probably going to always
have the dashboard.

I don't gravitate to Slack right now.

Like, I'm not someone who jumps into
Slack to have a conversation with AI.

I always think about
it being in my harness.

do you see it being like an MCP or an A2A?

I don't really understand exactly
how agents talk to each other.

I don't actually currently
have any of my own.

How does that, what does that
future look like for Mendral?

So definitely it's very interesting
topic and, so short answer is yes, yes.

I do also have a single interface and
I, constantly, tweak it and improve

it and customize it to, to my profile,
my needs, my skills, all of that.

And so, so, yes.

And, and today Mendral has a lot of
knowledge and he's building a lot of,

fairly large context at a given time about
your state of your software delivery.

And we started to get people asking us,
Hey, can I use that knowledge locally?

Because we are actually doing
a lot of things locally.

You know, I mentioned software
delivery is gonna change.

And one, I think one of the biggest
change that's gonna happen in CI/CD is

a lot more things will be done locally
on the machine, that's for sure.

And so, you know, starting with the
reviews, of code, like Anthropic released,

and there are more and more people doing
reviews locally before they land and

I think that's only the beginning and,
I think, um, eventually, we can expect

the, code to land on your CI to be more
and more perfect because there is a lot

more thinking and calls and and back and
forth happening on your local machine.

And so, yes, indeed, we want
Mendral to be available, locally.

so it can be included entirely with
the way you do work already and

also bring this knowledge before
it lands on CI, kind of sucks today

that every time you need to, there
is this big surprise that happens

when you have to kick in CI runner to

verify certain things
that you cannot verify.

Otherwise, I think that needs to change.

And so yes, in terms integration,

right?

Like, this is why you were working
on Dagger for seven years, yeah.

Exactly.

that's exactly right.

And, in term of implementation,
you mentioned, MCP, A2 A, I think,

think what's, where most people
are moving right now is by having,

really good, well documented CLIs.

' cause again, LLMs actually perform
Like the human brain, not at

the same level, but it's very
similar in the way it thinks.

And so do you think your software engineer
would behave better with an API and

MSCP server or with a great CLI, And
when you look at Claude and skills, it

actually works much better by using CLIs.

and so I think, um, MCP is
good for certain things.

but I see it.

Exactly the same as an
API API MCP same thing.

it actually works better usually when
you have remote MCP servers, but remote

API or remote MCP server, at the end
of the day, it's not very different.

Uh, and so I think the best way to
integrate with some of those APIs is

to have a really good CLI That your
harness, as you said, can integrate with.

And so that, that's what we're planning
to do eventually, is to have, A-I-C-L-I

that gives you all the capabilities as
you could get on Slack or the dashboard.

Those are just front end to the
engine that we run on the backend.

So yeah.

short answer, yes, and I'm glad you
asked because, I think it shows also

that you're, pretty advanced with
your own harness because not a lot

of people are not like that today.

You know, sometimes it feels, when
we're talking to each other, we're

like, yeah, of course it's obvious.

You know, need improve your skills,
your customization, your profile.

And I do that too.

It's just that so many people out
there who are still figuring out what

they should do with AI, you know,

Well, and the reality is that six
months ago I knew none of this, right?

We didn't even have skills
until six months ago.

Like there's just, yeah, there is so much.

And we're all, it's the only reason
I think any, any team that is in

our sort of level of maturity or
beyond is getting productive is

because the AI is doing the work.

Like we are, we're so consumed
with having to learn patterns.

I'm reading constantly.

I've had to adopt a ReadWise reader in
the last year as critical part of my

learning workflow where I just dump every
tweet, every blog post, every YouTube

that I think is interesting around AI
that I think I probably should consume.

I throw it in a read, shout out to
ReadRise Reader, uh, Readwise is the

company the product reader is the
app that you can consume all these

different types of media in one place.

And I can log, I can have it summarized.

I can tag it, I can do all
these great things with it.

It's kind of like to me, the graduation
of the old Feedly or the Google reader

or the RSS readers that we used to have.

But it's kind of becoming like my podcast
and YouTube player at this point too.

Instead of using the algorithms, I
just dump things into it that I think

are interesting from the algorithm.

And then when I want to be
focused and learn, I go there.

So that's like a hack for me
to keep up because well, and

I'm not nobody's keeping up.

Like this is a crazy time.

it's insanity.

no one can actually know it all.

No one's an expert yet.

So it's exciting to see that because
like, do you know specifically how we

would implement that in terms of me
having a Claude Code in front of me?

How would that talk to
Mendral, like getting into

your architecture for a second?

is that an A2A, I'm not
smart enough to know.

Is A2A the thing that would allow my
agent to somehow talk to like an API

on your system that has an agent.

Do you know anything about this stuff

yet?

so, I mean by a CLI is, I think a
good example of that would be look

at the difference when you use either
OpenCode or Claude Code, or even Cursor.

Like look at the difference of interacting
with GitHub with on one side, uh, GitHub

MCP, which is actually quite good.

And on the other side, the GHCLI.

I don't know if you tried both
actually, but, I invite you to do it.

you'll see that there is a huge
difference between the two.

Basically TLDR is one works really
well, the other is a bit clunky.

I'll Let you guess which one.

Well, the CLI is great because when
you look at the agent session and how

it navigates the CLI, it basically
reads, reads the help, it requires

your CLI to have really good error
messages so the agent can actually

react from it, basically, it's the same
thing like you, your, your CLI needs

to be intuitive so a human can use it.

If a human can use it well without
much documentation, it means an LLM

will use it pretty well because it
can read those messages and, and can

interact with the CLI and so yeah, when
we do, we got a lot more success with,

really good CLIs when we integrate
with services than anything else.

And then it's obviously your job as,
I mean our job for Mendral, to make it

work Well, you know, with our API and the
CLI, but for the user, and for both the

user and the agent, the, you know, your
local agent, like, it doesn't matter.

the, the CLI,

the CLI works well, is able to
expose the right context is able

to grab the right input and output,
and have, the right integration.

All of that is obviously complex,
but it's the problem of the person

building the CLI and the API behind.

So, yeah, I wouldn't think too much
about the best way integrate, like

you can actually write a skill, that
says, Hey, you have the CLI, X, you

know, and the CLI is to do this.

some context.

That's it.

The integration is done and it will
work much, much better any MCP server.

Yeah, I just realized while you're
saying that, maybe a question I should

start asking products that are on
this Agentic DevOps podcast is, are

you prepared for the AI to sign up
and use your tool versus the human?

Exactly.

that's like now we have Stripe doing
this, we have, people booking their planes

with AI and OpenClaw's doing all this.

And I'm wondering for companies that
are built in the AI era, and actually

using AI just like AI centric, right?

are they also, presumably thinking,
well, let's see how far Claude Code

can get just signing up and using the
tool implementing our preferences since

presumably your local harness knows
more about you and your infrastructure

than Mendral does on day one at least.

usage scenario that you're considering?

Yeah.

And, I think that's, you know,
there are, even startups right now.

Like, I think there were a few in our, our
YC Batch that are specialized in giving

access, like to, to all the services out
there, like booking a flight or anything,

giving it access to agent harnesses.

so for instance, creating actually A CLI
on MCP server to interact with some of the

services that today are only accessible
through a dashboard and some clunky ux.

so yeah, I think the web of tomorrow is
gonna be adjunct and, it doesn't, very

interesting because it's not so important
anymore to make, interface that's really

good beautiful for humans, but it's more
important that it's ergonomic to an agent.

so yeah, definitely.

right now for us specifically, Mendral
is giving you like a turnkey solution

in a few clicks, but I realized that
the integrations with other agents is

gonna be key moving forward because
what everyone wants is not a single

agent, it's actually a team of agent.

So even when you use Claude Code, you
are actually already using several agents

underneath, locally on your machine.

And when you call to remote, services,
you already have a team of agents with

some agents running on your machines,
some other agents running remotely.

And I think that's the future.

That's what people want.

Yeah.

All right, we're going to do
some rapid fires real quick, but

before that, I think I have one more
question on the future of Mendral.

Like we've been talking about GitHub.

Not everybody that listens to this
podcast is maybe using GitHub.

We've even got some people, Kurt, I'm
hearing news recently that some teams

are leaving GitHub for various reasons.

Are you, like, where do you
see going out the rest of 2026?

Do you have plans for other tooling, other
platforms, other, anything like that?

Like,

we're already working on some of it.

Yeah, we started to work with
bigger companies lately realized

that some of them have different CI
needs, you know, things like we got

questions for CircleCI, buildguides,
so yeah, we're gonna support them.

the Mendral today is, we talked
a lot about GitHub, because I

would say So, based on what we
see from people, it's probably 80%

percent of the demand, at least.

so big still, but do agree that it's
going to disappear over time, or at

least reduce, you know, for me, GitHub
is more like a protocol nowadays.

because when you look at bringing
a GitHub app that replaces GitHub

Actions with another, CI system, or
even replace the GitHub action runners,

or bring another review tool on top.

some people migrated to linear
instead of GitHub issues.

So yeah, everyone is grabbing a
piece of GitHub and integrating

with GitHub because they have to.

So it became more like an integration
protocol than anything else.

And so, we have to follow that.

And so we made Mendral CI
agnostic by design, from an

architecture point of view.

we haven't built all the integrations
yet because there is still a high demand

for GitHub Actions, but it's gonna come.

Yeah, I secretly wish that they
would just open source the, the

non open source parts, the API
essentially for GitHub Actions.

That way we can have local runner, like
we can have, we can do this all locally.

We can still, you know, I feel
like at some point the automation

engine behind GitHub Actions
is just going to be commodity.

And I'm looking forward to that future
because we do have all these rough edges.

It does feel like a very
low level, raw tool to me.

but I, you know, I absolutely love it.

you know, I use it every day.

I make money by selling courses on
it and stuff, so I obviously love it.

It's just, it's there's a lot there
that could be improved and, you know,

they would need, like, you know,
another hundred engineers on that

actions team to move at the pace that
I think it needs right now in AI.

I mean, you talk about this as
like, we need these other tools.

There's like a future
with these other things.

And even GitHub's, former own CEO has
left, started a new company, funded

I think 60 million by Microsoft, or
at least partly by Microsoft to help

solve this agentic coding problem.

They sound like they're going to be a
layer on top of GitHub, which again,

makes me feel like GitHub is becoming
like a cloud provider in a sense, just

for code, because they already have
been, but they're just going to be this

thing that we maybe don't touch that
much, and that lots of people are using

things on top of it, but don't ever
actually have to go there because the

AI is the one submitting, you know, I
don't type Git commands anymore, right?

there's so much I don't do, and the
only reason I think I'm even still going

to GitHub is because one habit, like I
got a lot of bad old habits to break.

I've got a lot of things that I should
be asking my local agent to do or look at

or go find out that I'm manually going,
doing, and doing, and I don't know why.

feels like I need to sometimes just
break myself the habit and see how

far I can go in the day without ever
actually going to the GitHub website.

Um, because you're right, like the
GitHub CLI is doing a lot more.

And now, I mean, even now we
have the Gmail, CLI like a Google

Workspace launched recently, a CLI.

so you can access all of these workspace
tools, Google Docs, Google Gmail, Google

Drive and all that stuff from a CLI.

So yeah, that, that's awesome.

the CLI future, I feel like is
strong and I'm here for all of that,

'cause one of my favorite things to
use go for is to buy, to make CLIs

for solving my own little problems.

And I've already got, like most
of us, I think probably half dozen

local projects that I'm just making
CLIs for my own use to feed back

to the AI to do things for me.

So it's just a fun time.

We could talk forever.

I love talking to you about this platform.

but a couple of quick
fires for the audience.

I think I'm gonna need to start
putting these in my show just to start

asking engineers that are on the show.

current favorite harness.

Oh, I use Claude Code a lot actually for,

even more than code.

Yeah.

I start to customize it for
automating some of my non

technical work too, actually,

Okay.

Are you into, like the new Dispatch
and the Computer Use yet, is that

like for personal stuff or for
things that aren't necessarily code?

Are you leaning into some of
the cloud stuff with Claude?

so usually I use a combination
of, a couple of things.

I, I like a lot of the Anthropic products
and so, I use Claude Code, the CLI,

uh,

locally for most of the.

The code, I started to automate, a lot
of my code boring work, even with Claude

Code and some integrations locally.

And so I maintain like a catalog of
skills, uh, of personal skills that

I used to automate some of my job.

The problem with Claude Code is
that very specific to code also.

So I'm aware of that and so sometimes I
go to Claude Desktop, which I think has

a lot of, you know, a way of managing
the context that it's entirely different.

The way it manages memory and
context is very different.

So I like Claude Desktop.

I do not like Claude Cowork, Actually,

That's some of the things that
people start talking about and

like, I do not like it because I
think it's not as advanced as Claude

Code in terms of context management
and multi agents and all of that.

I think it will get there eventually.

Yeah,

and then I started lately
and that, one might make you

laugh, but it's kind of weird.

started to use the Claude Code, iOS app.

the cloud app, has a
Code, tab or something.

you have a kind of a tiny version
of Claude Code inside your

mobile, and it's using sandboxes.

And so I started to use that to make
some very simple PRs on the repo.

use that only for very simple stuff,
you know, like, oh, I need to update

that on the landing page or something.

I do that from my phone.

And that's kind of scary because it
works quite well for simple stuff.

So it's almost like a preview of what
we're going to be able to do tomorrow, you

know, like almost like talk to your phone
or something and work happens and code

gets pushed to progress.

yeah.

so,

I feel like we're so close to, you
know, the Tony Stark Iron Man, Jarvis.

feel like we're getting so
close, at least for developers.

Like, I feel like we're the
first wave of really the people

that are onboarding with this.

I went and saw last night

For the third time in two weeks,
I went and saw the movie Project

Hail Mary, because I read the book.

My wife and I loved it.

We're big Andy Weir fans, and this
new movie is amazing and perfect,

and Ryan Gosling is fantastic.

And we sat next to some people that
were I'm really, really into it.

And so we started talking the fact.

the movie theater.

the kind of person that
loves a full movie theater.

think the reason you go to movies is
to the experience with other people.

So the guy next to me, leans over at the
end and says, we started talking about the

movie and how it's a positive experience.

view of the future where the world's
actually collaborating and working

together to solve esoteric problems.

And he said that there's this
subreddit he's a fan of called,

I think it's called Humanity.

Hell yeah.

Or Humans, hell Yeah.

Or something like that.

That's like a post war Look at the future
of civilization where we all tend to agree

on that and we're solving bigger problems,
we're dealing with aliens or whatever,

and then we all just, hold hands.

And so we start talking back and forth
and I get home and I'm walking the dog

want to know more about this subreddit.

So I'm in the OpenAI app, and
the ChatGPT app essentially.

And I'm having a a speaker
conversation in the audio mode.

And I'm just talking back and forth with
the AI and I'm living in a little bit of

an urban area, so there's other people
walking their dogs and I'm realizing that

people around me are hearing someone.

I, I sound like the old guy on
speakerphone walking around talking

to someone on speakerphone, But I'm
actually just talking to an AI about a

subreddit and sci fi, and I'm realizing
that I'm walking my dog and I'm way

more advanced than everyone around me.

I'm like doing things that are sci fi
level, future where I'm talking to a

robot, but also I look like grandpa,
talking to someone on a phone, on

speakerphone, that's way too loud.

It's like really weird scenario.

So I feel the same way.

Like think these things are all, happening
so fast and it's very cool to do.

Um, okay.

last question.

I'm assuming you're using Opus a lot.

Is that your, uh, your, Opus 4.

6 person or are you open 4.

5 person?

know some people that didn't jump into 4.

6.

I like Opus 4, 6.

But, actually not using it for everything.

I'm a big believer of, the
right model for the right task.

Mendral also is built this way.

We use Anthropic models today,
and we're going to move, multi

models, multi providers, soon too.

I believe there models that are
really good for certain things.

Opus is really good for complex
reasoning, but it's also very slow.

And sometimes you don't, need to,
like, if you summarize an email or

something, or like if you want to
rewrite some things that you wrote.

so yeah.

but I'd say if I have to pick one,
yes, that would be my go to, but

yeah, usually I multi modal
based on what I'm doing.

Nice.

thank you so much, Sam, for being here.

We could talk for another hour.

People are already going to go, Bret, like
you can't keep having these multi hour

podcast episodes, but I feel like there's
so much to talk about and it's great to

actually talk to not just founders, but
engineers in the thick of it that are

also living and drinking the, you know,
the Silicon Valley Kool Aid a little bit.

it's great to see the different
levels or I guess maturity levels of

everyone, that we have on the show
and to see where everyone is at.

And always fun to have people
on the show are ahead of us.

And I feel like, you know, touching
the AI even closer to what we think is

the utopia of this Star Trek future.

I feel like we're in.

So I'm excited that you guys are
progressing so quickly on the

product and I'm looking forward to
using more of it, especially since

it's scratch is a niche for me.

I'm looking forward to having you back
on the show maybe later this year and

talking through some of the advancements.

We'll probably have new models by then.

Supposedly Claude's going to have this
amazing new model later this year.

We'll see see whether it lives up to
the height, but, it'll be interesting

to see what you can do with some
of the new stuff that's coming out.

Yeah, thanks.

a lot for the opportunity to share
all of that and very, very cool.

Didn't feel like a time at all.

I'm glad.

I'm glad.

Uh, so yeah, you can find Mendral
at mendral.com, M-E-N-D-R-A l.com.

well thanks again, man.

Thanks for joining us, and I'll
see you in the next episode.