Ship It Conversations: AI Coding Outruns Software Delivery, With Darko Fabijan of SuperPlane on What Breaks After the Pull Request, Change Risk Scores, Onboarding AI Agents Like Engineers, Read-Only Ops Agents, and Why the Answer Is More Automation

Transcript

Picture a dam built for a calm river. Now the

river's running way faster than anyone planned

for. And the water is pouring right over the

top. That's what AI-generated code is doing to

everything after the pull request. The reviews

and approvals downstream were built for people

working eight hour days. My guest today says

AI feels like alien technology that dropped from

the sky and we don't know how to control it

yet. But his answer isn't less automation, it's

more. And he thinks that we should onboard an

AI agent the same way we'd onboard a new engineer.

I'm Brian Teller from Teller's Tech, and this

is Ship It Weekly.

Welcome back to Ship It Weekly,

where I filter the noise and focus on what matters

when you are the one running infrastructure and

owning reliability. Most weeks, it's a quick

DevOps, SRE, platform, cloud, and security news

recap. In between those, I do conversation episodes

with people building and operating these systems.

Ship It Weekly turns one this November. To celebrate,

through mid-December, you're getting two conversations

a week, Mondays and Wednesdays, with the news

every Friday. Then, we're back to our usual rhythm.

Today, I'm joined by Darko Fabijan, CEO of SuperPlane

and co-founder of Semaphore, the CI/CD platform.

We talk about what starts breaking after the

pull request when AI is writing more of the code,

what should sit between an AI agent and production,

why he thinks you should onboard an agent the

way you'd onboard a new engineer, and the first

workflow he'd actually trust AI with on an ops

team. All right. Let's jump in.

Darko, thank

you for joining me. Thank you for having me.

Developers are using AI to write more code faster.

What starts breaking once that code hits the

real software delivery and operations workflow?

Well, yeah, I think that we are very fast with

generating code. I mean, some are also very fast

at putting it into production, but there are

just some numbers that are not as they used to

be. So I think definitely it's a time of, you

know, stability and, you know, various other

metrics when it comes to the quality of, you

know, what is more hitting the developers back.

But, you know, for the operations people, it's

just that code that we are shipping, you know,

it just has more bugs and it's just by nature

of things. Pull requests are bigger. They are

more frequent. The pressure is all over the place

just within the industry of like making software.

So there are like a couple of forces that are,

you know, just very new and things are breaking

in various shapes and forms. Yeah, I would not

say only in the production and operation, but

kind of also in the society a little bit. It's

just the velocity and the amount of things that

we're putting out there. Is the post-PR world

becoming the harder part of engineering? Or you

had mentioned the social part as well, but what

is becoming harder specifically from the changes

with AI? I would say, I mean, operation side

of things is becoming harder. So if I'm just

thinking from these numbers perspective, so the

complexity in the software is increasing just

by the numbers of lines of code that are being

put out there. The frequency of those deliveries

is increasing. I mean, in the good old, you know,

CI, CD practice, continuous integration as a

practice is you want to ship, you know, small

chunks of changes because then you minimize,

you know, the blast radius, you minimize the

surface area. Now the pull requests are just,

you know, bigger. It's getting kind of out of

hand, you know, what's the size of the thing

that we are shipping. I mean, I'm seeing it in,

you know, in our team and I'm hearing it all

over the place. You know, those pull requests

of a couple of thousands of lines of code, you

know, who can manage that. And I think that,

I mean, it's not, I think it is getting out of,

you know, cognitive capacity of people to just

want to review all those pull requests. And it's

just that, you know, things are getting into

production that are not really that well reviewed

and are causing the issues on the other side.

I don't know the exact URL, obviously, by heart,

but there is a Faros.ai report that recently

came out. And I think we can link it probably

somewhere. There is an increase in the number

of defects that are being shipped, in the number

of incidents. So it's all between 50% and 200%.

That's my kind of rough understanding and memory

of how those charts look. And it's all in red.

So yeah, that's one side of it. I've seen this

in my day job as well. Like we have AI agents

creating code using Claude Code or Cursor or whatever.

And then you have AI agents reviewing code. Like

you have like a Codex plugin on maybe GitHub

that reviews the PR. And then you have maybe

even AI in your CI/CD pipeline, like in your actual

delivery pipelines as well, where it's interfacing

with the production. Where should AI agents not

exist? Like where should we not have AI or still

have like very specific? Because again, it's

non-deterministic, right? So at a certain point,

how can we reduce that risk? Well, one way we

can reduce it is by having more AI. But it takes

time to figure out how exactly and where to put

that AI. So in terms of unsolved problems, it's

definitely the right access to production systems.

So people are not really into that. There are

some people that are. I think it's, you know,

sub 1% of the industry at best, but people are

trying to solve that. And we are also trying

to solve that also in our own ways and industry

as a whole. In the broadest possible sense, I

would say I understand the situation. Yes, AI

exists for the last couple of years in this form

that is, you know, usable, but in just like last,

you know, six to nine or something like that,

it has really become, you know, super powerful,

you know. And I perceive it as that, you know,

alien technology has dropped from the sky and

we don't know how to control it. Part of it is

that in our process of producing software, there

are still so many things that are manual in various

ways. I'm not saying that we are creating EC2

instances by hand from console and all of that,

but the processes are just not made for the AI.

Processes are made for humans. So there is, you

know... The time that the human being, you know,

can, you know, review something, understand something,

you know, work those eight hours a day or, you

know, a little bit less, more on the day and

so on. So that is a very recent phenomenon of

us being to create so much code at such a velocity.

But other parts of the system are just not made

for the AI yet. And that has to change, you know,

iteratively over time. In the same way that we

are introducing change in the production systems,

we want to make one change at a time and control

the risk. And that whole pipeline has to change

fundamentally, but it cannot change overnight.

We have to figure out and understand how to change

it so that velocity that we got to that AI creation

side. So yes, I can write like 10,000 lines

of code in three hours of live coding, but how

the rest of the system... can really deliver

it and work and how we can handle that amount

of change. So that has not been figured out.

So kind of our main hypothesis is that there

needs to be more automation and we have to figure

out what that automation is and what's the nature

of it to be able to really fully harness and

control, I would say, mainly control the risk

that this power that we just recently got has

introduced. So I would say that's... part of

the, that's a part of the, of the answer. I mean,

definitely, other, the other piece that I mentioned

is how do we give agents the right access to

the production systems. So policy enforcement,

that sort of thing. Yeah, or least privilege.

Yeah. We need to figure out like what that kind

of automation is and how that layer works. Is

that like a fully deterministic layer that exists

between, you know, AI agent and the production

systems? I currently believe that that's a part

of the equation and then it's going to be part

of the equation for, you know, significant period

of time. There are some people that we are operating

against, like, that hypothesis. There has to be

a deterministic layer in between and there are

automations and right access that we give to

the to production system to agents, but it's very

scoped, very limited, goes through the approval

process. But as I'm speaking with, you know,

various people from industries and some, you

know, very, you know, advanced companies recently

spoke with a guy from Nvidia. So they are trying

to figure out how to give more, you know, right

production to their systems, you know, in their

own way. And that's also our hypothesis that

there has to be that guardrail, you know, layer

in between. To be able to do that. Yeah. I'm

curious, what are your thoughts on that right

access to the production system? Because it is

a very uncomfortable thought to a lot of people.

Yeah. So, well, OPA policies, Sentinel policies,

as far as like allowing changes and then on the

actual production side change, having approval

gates, like having least privilege and maybe

gating those AI agents, I guess would be my answer.

I don't know that it's... That's a full answer,

though. A lot of the AI safety advice says keep

a human in the loop. But what I find is in a

lot of real ops, humans end up just rubber stamping

stuff all the time anyway. So that part, I don't

know how to fix. How do you avoid those fake

approvals where it's just rubber stamping the

AI changes? That's a harder challenge that I'm

not sure. And I think if you can solve that,

it makes way to the least privileged conversation,

the OPA policy conversation is an easier gating

strategy. The harder part, I think, is the human

side. Like, how do you fix that human side? I

mean, I recently heard that, yes, AI agents hallucinate

and are unreliable, but also humans are hallucinating

and are unreliable. So that side of the thing.

I mean, whenever there is a system that has a

lot of something in it, you have to... quantify

various kinds of things. So there is like a code

coverage, let's say, if you're developing something,

is everything covered by tests? What's the quality

of that code? There are like various metrics

to assess that. And there's, you know, change,

any change, you know, pull request, either your

Terraform code or on your, you know, Java code,

it doesn't matter. There are various, you know,

heuristics, numbers that can quantify how dangerous

is that change. So as we are shipping, you know,

this code, I mean, last week, I mean, we, we shipped

kind of 50, 50, you know, thousand lines of code,

you know, and it's, you know, five, six people. Okay,

we are rushing and, you know, it is, you know, kind

of pre-production software and, you know, all

of that. But it's, it's such a, such a big, you know,

such a big change that we are introducing the

system that I was thinking in terms of just pull

requests, so can we have some kind of like metric

in place? So if this change is just changing maybe

the, you know, but name of the bucket, you know,

if it's like, you know, Terraform or, you know, changing

some, some smaller thing, you know, it should get

the score. So it's not very dangerous. If I'm deleting

the resource which is a data storage thing, either

S3 bucket, RDS instance, I mean, that's 10 out of

10. That, that's a red. I have not, maybe I don't

know, but I haven't seen that kind of like metric

that exists yet in the industry either on the

development side or the ops side. I think that we

need that kind of thing because of the rubber

stamping that you're mentioning. Sooner or later,

someone is going to be tired and there is going

to be a line which is going to be like drop all

tables because, I mean, we have seen that recently,

last couple of months. There have been some drop

all tables scenarios around. So, yeah. Yeah,

I was trying to think of that because, yeah,

dropping an instance or deleting something from

a bucket or removing a database, that's an easy...

gate to have, and that's an easy score to score

on a metric. The problem I would think is with

ancillary processes, like a Lambda that maybe

does some data manipulation that could potentially

also, maybe there's an unintended change and

it's down the road and you're deleting objects,

you know, and that's not, it's harder to understand,

I think, to actually quality gate that because

there could be related resources with unintended

consequences further down the chain. Absolutely.

Absolutely. But I mean, that's an area where

theoretically, I mean, we spoke about AI writing

code and reviewing it, then, you know, approving

it. Yeah, no, I know. Yeah, that's a hard problem.

Yeah, it's not solved either. I would say just

the area of like qualifying the risk. That's

a billion dollar startup idea over there. And

I mean, it's just, there's a lot of work to be

done in the area. I guess there are some, you

know, research going around some universities

around qualifying that. So you have all of these

different services that are part of your control

plane, and you have scripts that are all glued

together. Most ops teams already have some version

of this held together with GitHub Actions and

a Slack app and maybe Argo CD and Argo Workflows

and scripts and runbooks, maybe Ansible, whatever,

dashboards, and probably in someone's memory

somewhere. What's wrong with that model and how

do you solve it? I don't think there is like

anything particularly wrong with that model.

It's just the question of like how AI can interface

with that in the best way possible. So part of

our hypothesis that, you know, there needs to

be like a bigger context for AI to be able to

understand the system. And a lot of what you

mentioned ends up being, you know, what I like

to call those point solutions. So there are things

which are in PagerDuty. There are things within

your GitHub Actions. There are some things in

your repo. Some things are in CloudWatch or Datadog.

So things are all over the place. And I think

it's a situation for the vast majority of the

companies. Yes, there are companies that are

fully AWS. Nothing goes out. I think in that

situation, it's a little bit easier. It's about

giving that context and figuring out, you know,

what should go in that context so decision can

be made. So I would say that's one piece of the

puzzle. There is also a question of coordinating

and how AI can coordinate those things and, you

know, stitch them together. And when we get to

that question, we have to get into that question

mark of which API actions can AI call and which

API actions AI should not call. That can be solved

through, you know, policies, you know, various

guardrails, approvals and all of that. But as

our industry, it's not science. It's not art.

It's between art and science. And we have been

running in loops in our industry for, you know,

many times and, you know, creating things over

and over, like every decade where we create things.

So I would say... We are now at a stage where

everything is getting recreated. Each service

is going to be recreated from scratch to maybe

suit the agents a little bit better. And it's

about, I would say, scale and velocity. So historically,

everything was made for humans. I mean, each

service that you can imagine, it's made for humans,

including programming languages and so on. So

now the more the conversation is, okay, all of

those services need to speak with AI. Some need

to be rebuilt from the ground up. It's great

for the new generation of builders. Everything

that my father and grandfather built, let me

rebuild it from scratch. Some for very good reasons,

some for not. And then in that rebuilding, the

question is, you know, how do you treat actually

human? How do you treat agent? Are they on the

same level? Are they somehow different? So it's

about, I would say, becoming the reality in every

part of the system. How is SuperPlane different

from Argo Workflows or n8n? I mean, our main

hypothesis, let's say, the space that we operate

in is essentially software engineering operations,

both of those domains. And we specifically want

to treat, we want to start with that, that both

agents and humans should be kind of on the same

on the same plane. They're not today. It will

take time until that becomes the reality. But

where we are building service, we are building

it from the ground up from that perspective.

The other element is how do we give AI right

access to the production, which is a big unsolved

question within the industry. And our solution

here is that we need more automation. Automation

in that very, I would say, traditional sense.

But we need to expose that in a very controlled

way. So I like to think about that story as we

are onboarding, let's say, the DevOps engineer within

the company, or we are onboarding the agent.

So what are the things that are available to

me? Where can I apply my Terraform change? What

can I do? What can I introspect? So I like to

think about the agent as something that has the

identity. It's entering the system. Okay, let

me do the introspection. Let me see what are

all the things that are available to me so I

can be productive. And that onboarding piece

is an angle how we are telling our story. In

the same way that we want to make super easy

for DevOps human to onboard the production system

as we understand everything, and that should

be there is no half-rotten documentation, tribal

knowledge, all of that. It's all codified. It

works, flows. I can click on everything. I can

understand how things are flowing, how things

are being done. And that hit by that bus factor

is removed. So it's the source of truth is, you

know, there. Once we reach that level, and that's

going to take time for the industry to, you know,

just introduce more automation. I would say at

that point in time, it would be easier to onboard

also like a dev, you know, DevOps AI engineer.

like in a way to be able to help with things.

And I generally don't go for that, you know,

doomer scenario where, you know, us engineers

and, you know, crafters are going to be removed

from the equation. I mean, it's obvious that

things are going to change, but, you know, taste,

direction, you know, all of that is going to

be present. So I'm more in that scenario that

things that we have not historically, we didn't

have time to solve. Because it was too expensive.

It was too expensive to write software. So I'm

more in that category that, you know, we will

need more engineers on all sides because there

will be just more software. Yes, the roles will

change and some will change drastically. And

we'll have to figure out how that works. So when

you say more AI and onboarding, are you talking

about like a multi-agentic workflow? Like where

maybe I have like an agent for just Terraform

or just IaC in general? And like that agent only

handles that? Or is it even more fractured than

that? Like an agent that only handles like creation

of objects or resources? And how do you think

about that model? Like, how do you frame that?

My hypothesis is that it's not going to be like

that. It's going to be within this team that

is handling maybe... encoding and stream in Riverside.

I don't know how they're organized, but let's

say they have a department which is more for

this, you know, video transformation, production,

whatever team, there they will have an agent who

will have a specialized set of skills and understanding.

So it will know that there is like a throughput

and latency are very important. So maybe I'm not,

I don't even write, you know, Terraform. I don't

do this. I have some specialized functions for

my team and the context is very based on that.

And I'll have that maybe one monitoring agent,

which is really in charge of, you know, maybe

scaling and latency, understanding what's happening

in the world, you know, within the AWS network.

And there is a glitch and then what I can do.

My sense is we're going to be very specialized

and small and scoped. And that agent is going

to take care of that. Of course, it does make

sense that there are agents and there will be

agents that will be very, very specialized in

Terraform, OpenTofu, whatever, resource creation.

But I'm more on this side. How do we fit? How

do we find help? How do we find that small agent?

Not replacing anyone, helping someone with a

very specific task, which is maybe more suited

for AI because there are a lot of numbers and

metrics and less for human. Yeah. Do you think

that compliance and audit requirements change

when part of the workflow came from an AI agent?

I think that they are going to change. I think

the change is going to come by this, you know,

velocity, which is coming in. So whenever I think

about this, you know, code creation in AI, I

imagine like a dam and a river. And like river

is so strong and it's, you know, overflowing

the dam and, you know, you have to do something

different. So I think that, you know, compliance

piece will have to change and we have to figure

out how that will work. At some point, agent

is probably going to have to carry, you know,

some element of responsibility in some shape

and form. No clue how is that going to work.

I would say... Maybe this, you know, self-driving

cars industry will maybe, you know, teach us

something. So if I get killed on the streets

of San Francisco by Waymo, who is responsible?

I know that they have some framework. They figure

it out, you know, one way or another. So if like

a database, you know, a database table or, you

know, whatever gets dropped or, you know, some

data corrupted or leak or whatever, whatever

other way. There is going to be some legal framework

around that. I wish I have an answer, so I don't.

I'm just, you know, thinking out loud. I think

it touches the law and those areas also in various

ways. What's the framework there? If something

really bad happens in a publicly traded company,

they have various policies in place. I would

say that's the domain where probably the biggest

guys should solve it and let us know what to

do. So I would say, you know, Google, Apple,

whoever has the most AI, the biggest production,

all of that, and the rest of the industry would

follow us. So I would say it's not my job and

of many other folks. But it is an interesting

topic for sure. And one thing that feels very

real is how much production knowledge lives in

people's heads. How should teams capture operational

memory without pretending that documentation

will stay updated? How do we solve that problem?

Again, getting back to our hypothesis at SuperPlane

that we live by, I think it's about automation.

So as things get more and more done through the

automation, the more records do we have about

what happened and when and why and whose approval

and whose idea and which prompt and so on. So

all that's tied into a chain of a decision chain,

how we came to that. So that's one piece of the

puzzle for sure. How in practice that gets pulled

off, we'll see. I mean, in terms of documentation,

I think that all documentation should be, kind

of AI-generated by those by those automations

that we have, you know, in place, again, iteratively

getting that piece by piece. But I think that's

the main piece. That's the main piece of the

puzzle of that. Yes, AI definitely is better at

maintaining documentation over practitioners,

just given that, you know, practitioners can

get lazy, right with comments, or just markdown

files and AI will be much more verbose, but not

overly verbose, like concise in its verboseness.

I agree with that. It's also about generating

the documentation. So I think it will be each

paragraph sentence, I think should be clickable

in that documentation with like some decision

tree. How do you came up with that conclusion?

Because if I perform some action based on like

incorrect documentation, I do something bad.

I need to have that chain. Okay, you inform.

You gave me something, you know, some misinformation

based on some, you know, wrong reasoning. And

then we should be able to have like root cause

analysis of what caused that. So in my head,

I mean, we are not there yet, but we have some

elements in our documentation generation where,

you know, you have a sentence or you have a certain

action and you click on it and it links back

to some part of the workflow and you see, okay,

how that, you know, documentation came

came about. So, and I keep going and kind of maybe

defending not knowing the answer and saying about

that has to be done, you know, iteratively. So the

whole documentation generation problem. I think

we'll have to, we'll have to get into that check

that we should know how each line of that documentation

was generated and, you know, it traced back to some

to some code or some fact some configuration

somewhere And then how do we keep that in sync?

Is that eventual consistency or whenever I change

some configuration, my load balancer, is that

immediately reflected on the documentation? What's

the gap, you know, between that? Again, one of

the areas that deserves a special kind of attention,

especially because of that, as you said, no one

likes doing that. So our industry is awful, you

know, when it comes to having like up-to-date

documentation. Yep, for sure. Every company I've

worked at, you go on Confluence and there is,

you know, a document that hasn't been updated in

three years and the process is not even the same

anymore. You know, that's the only document that

exists. Or you're trying to hunt through Slack

to find, you know, a conversation that engineers

have had. And that's a real problem, I think,

yeah, that is just not solved at a lot of companies.

And AI definitely can help with that 100%. Okay,

so wrapping up, if a platform or SRE team wants

to start using AI in infrastructure operations,

What's the first workflow that you would trust

it with? Like, where would you start? I mean,

it's definitely this, you know, read-only mode

where I would want it to explain me how something

is done and point me in the right direction.

So if I'm onboarding like a brownfield project,

let's say on AWS, it has some complexity in terms

of the, you know, software stack, infrastructure

stack, all of that. I'm generally, what I really

like is that, you know, I pretend to be super,

super stupid, you know, and just a lot of

dumb questions and like onboard me, help me understand

how system works. And then I ask, okay, what's

the smallest possible change that I can do on

the system to just help me get, you know, some

deeper understanding. I think that I could be,

I could misinterpreted your question. So feel

free to, you know, dig deeper. But I mean, for

me personally, that's, you know, discovery phase

is like what I would do as a first step. Yeah.

Okay, so let's say we've done discovery phase.

We've done read only. It has the context of our

entire IaC. It knows our deployment stack. It has

access to GitHub, so it knows all of our GitHub

Actions that we use for our CI/CD platform. It

maybe even has access to Grafana and Prometheus

endpoints, so it's getting monitoring. All read only.

What would be the first write operation? Where

would you feel the safest starting giving that

autonomy to an AI agent to start writing? I mean,

I would say we have two big categories here.

One is the creation of, you know, just the change,

which is, again, writing some code. So it's either

Terraform or, you know, Java code within our

application. That's one domain that goes through

a review process. And then that's, you know,

being applied in production. I would say that's

the category where you have human in the loop

approval process, which is lowering the risk

there to some extent. And that's what happened

in the industry at scale already. So, I mean,

I haven't said anything new. I just kind of described

the reality that we have today. I would say maybe

the first next step after that are... I would

say in that category of these loops that we keep

mentioning. So if we want to move some metric,

you know, want to lower the latency of a certain

system, then I would say I would work on those

numerical things that are like easy to measure

and easy to test. So yes, we have some response

time somewhere. It can be due to the way the

code is written or how infrastructure is configured.

And maybe we want to have like a faster disk,

faster database, whatever. And I would say it's

in that performance optimization area. What are

some of the incremental steps that we can make?

And then we apply that to copy of production

or staging environment, whatever. Do some testing

and apply that change in production. In the same

way, I would map it to how can I improve the

speed of my GitHub action, which is, you know.

running my code and I would, it is also how can

I lower maybe the number of CVEs like in my system,

there are auto security tools that are minimizing

that. So I would say I would keep it in that

realm where we can easily measure the impact

and it's a numerical value. And we, we, we, we

go, we go from there. Yeah. Yeah. It makes sense.

Any closing thoughts you'd like to leave our

audience with? I would say I would get back to

the automation and I would say we as an industry

and discipline, hardware and software together,

we have been going out and changing factories

and many, many other industries for many decades

and automating things, automating things, you

know, factories, removing workers, like all those

kinds of bad things. Now the lens has kind of,

you know, shifted in the other direction and

we are getting automated and, you know, also

feel threatened a little bit and all those emotions

that we're feeling. I think that's okay and everything

is going to be okay. We just have to embrace

that automation and go after it as soon as possible

and just embrace the change that are happening

to our roles as that is happening. So with any

technology, historically, you can fight it or

you can embrace it. So I would say let's just

embrace it. You know, bring that, bring that

automation and, you know, figure out there is

going to be a lot of, you know, a lot of infrastructure,

a lot of everything. And yeah, those are my thoughts.

So more automation. More automation. No, I got

you. Where can people follow you? SuperPlane,

Semaphore? Yeah, superplane.com. That's, that's

our thing that we, that we are doing and trying

to solve that, you know, write access to production.

Easy problem. Easy problem to solve. But yeah,

we are doing it iteratively in that, you know,

a lot of determinism in place. So we want to

be cautious and, you know, do good things there.

And semaphore.io, previous company in the CI/CD

domain and DarkoFabijan at X. Yeah. So feel free

to engage. A lot of, you know, hard topics to

discuss. We love them. And I'll put links for

all those in the show notes as well. Darko, thank

you so much for coming on. Really, really appreciate

it. That was my conversation with Darko Fabijan

from SuperPlane. The biggest takeaway for me

is that AI didn't break software delivery. It

exposed how much of it still runs at human speed.

Darko's dam and river image nailed it. AI-written

code is the river and the dam is every review

and approval we built for people. I also liked

his take on rubber stamping. He pointed out humans

hallucinate too. And sooner or later, a tired

reviewer approves the line that drops all the

tables. So he wants a risk score on every change.

Renaming a bucket scores low. Deleting an S3

bucket or an RDS instance is a 10 out of 10.

He called that a billion dollar startup idea.

and I'd buy it. His agents as new hires idea

stuck with me too. Give the agent an identity,

let it look around, and keep a deterministic

layer between it and production. The work that

makes an agent easy to onboard helps your humans

too. No half-rotten docs, no tribal knowledge,

no bus factor. Where to start? Darko says read

only. He likes to pretend that he's super stupid,

ask a lot of dumb questions, and say, onboard

me. When you do let it write, pick something

you can measure with a number, like latency.

You can find Darko on X, plus SuperPlane and

his previous company Semaphore through the links

in the show notes. Follow or subscribe to Ship

It Weekly wherever you listen and find previous

episodes at shipitweekly.fm. Thanks for listening,

and I'll see you Friday for the news.

Ship It Conversations: AI Coding Outruns Software Delivery, With Darko Fabijan of SuperPlane on What Breaks After the Pull Request, Change Risk Scores, Onboarding AI Agents Like Engineers, Read-Only Ops Agents, and Why the Answer Is More Automation

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

👤 Guest

More from Ship It Weekly

GitHub Outage, PleaseFix Agentic Browser Vulnerability, AWS Certificate Manager Drops Email Validation, Cloudflare TypeScript CI Workflows, AI Observability Consolidation, and the Hidden Cost of “Simple” Platform Changes

Ship It Conversations: Ned Bellavance of Ned in the Cloud on DevOps Beyond the Buzzwords, Terraform, AI, the Future of Infrastructure as Code, and Why Fundamentals Still Matter

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

LiteLLM Release Pipeline Hijacked Again, GitHub Package Firewall, PHP2Shell Core RCEs & eMudhra CA Keys Compromised

Get the next episode in your inbox