Ship It Conversations: Mike Lady on Day Two Readiness + Guardrails in the AI Era

Transcript

AI can crank out code fast now. The part that's

not speeding up is our ability to ship it safely.

And if you don't have guardrails, you are basically

just moving failures faster. Hey, I'm Brian.

I work in DevOps and SRE, and I run Tellers Tech.

Ship It Weekly is where I filter the noise and

focus on what actually matters when you are the

one running infrastructure and owning reliability.

Most weeks, it's a quick news recap. In between

those, I do interview episodes with folks who

are actually building and operating real systems.

Today is one of those interviews. I'm joined

by Mike Lady, a senior DevOps engineer and the

creator behind Enterprise Vibe Code on YouTube.

Mike's deep in distributed systems, and we're

talking about day two readiness, guardrails,

and why that stuff matters even more now that

AI can generate code fast. We get into what day

two readiness means in plain English. the symptoms

you see when teams ship without guardrails, what

a real day -two audit looks like, and how Mike

thinks about AI can write code, but it can't

ship safely without gates. We also talk about

AI agents watching builds, branch protection,

quality gates, and where the line is between

AI -assisted development and AI taking actions

in production. All right, let's jump in. Today,

I'm joined by Mike Lady, a senior DevOps engineer

from Enterprise Vibe Code on YouTube. He's focused

on distributed systems. And we're talking about

day two readiness, guardrails, and why the ability

to ship safely matters even more now that AI

can generate code fast. Mike, thank you for joining

me. Thanks. Thank you for having me. So I'm curious,

give me your thesis on why do guardrails matter

more than good code? I feel like it's a kind

of... process like we we can we're constraining

people and ai to create like uh code that meets

the bar meets a certain standard i feel like

these it's the it's basically the same thing

a human generated code ai generated also all

go into the same like pipeline all go into the

same like build test deploy phases right so i

feel like people are freaking out like making

a big deal out of this when we have the same

system for people as we do for AI code, right?

And ultimately it's people reviewing and approving

this code anyway, right? So I feel like this

is, I don't know, we're in the same thing. We're

still doing the same thing and we can do it even

better now in the age of AI -aided development

or five code, whatever you want to call it. People

like to call it different things. So for sure,

yeah. So what do you what is day two readiness

mean in plain English for people out there that

may not know the term or understand the meaning

behind it? At least for for what how I'm talking

about is like day zero is like you don't have

an app. You just have an idea. Day one is you

launch the app. You go from zero to one. You

launch the app. Hooray. You you have something

on the Internet that people can use. And the

day two is the part that comes after that. It's

like. How do we maintain this long term? How

do we add new features? How do we fix bugs? How

do we add security updates and whatnot? Like,

how do we change the app over time and maintain

it? Because it's one thing to go from zero to

one, make it, and that's like the first part

of the work. It's a much longer, much more long

tail of work after day two, basically. Yeah,

for sure. So what symptoms do you see when teams

don't have guardrails, typically? They just pray.

They put code into production and just hope that

it works. There's some famous quote, it's like,

hope is not a strategy, right? You want to be

able to try to prove out that this code that

you make is as correct as possible. So if you

don't have guardrails, you're going to have weird

bugs, you're going to have features that just

completely get deleted or something like that,

or just don't work. Your users are going to be

pissed. It's just not a good thing to just kind

of ship, like merge directly to main and then

ship that directly to prod and just blindly do

that. Yeah. So do you think that guardrails end

up slowing teams down or speeding them up? It's,

yeah, ultimately speeding them up. People who

are like really... I don't know, early startup

run and gun. They're going to feel like, oh,

it feels like it feels slow. It's more process.

Like we can't get things done. Like we have to

fix the tests. But like now in the age of AI

driven development, vibe coding, it's like the

AI can do all the hard stuff for you. Like it

can like write the tests. It can fix the tests.

It can. do all the stuff that you don't want

to do. And then you can focus on the stuff that

you don't want to, you want to focus on with

features and whatever bug fixes that you want

to do and kind of product development. We get

to operate at a higher level now rather than

dealing with the build breaking, right? Like

we could just say, like my favorite thing to

do with AI agents is to have it watch the PR

build and it monitors it. It sees the, whatever,

the break, like whatever. thing it fails on and

then goes and tries to fix it. And just it goes

off in its own loop and just works to make the

build pass. Of course, I need to check the code

to make sure it doesn't like just delete the

test to make the build pass. Right. But like

there's a certain like abstraction or certain

like like I'm giving the agent a little bit more

control autonomy. I'm delegating the boring developer

task of, all right, fix the build. type of thing

so i think i got a little off track of what you're

going but no no speed up versus slow down yeah

so ultimately it speeds you up because you're

not dealing with all the failure like all the

bugs that crop up if you don't have guardrails

so yeah i i think too it goes back to like the

whole philosophy between but behind iac like

slowing down to speed up yep to a certain degree

but even that barrier is gone now to a certain

degree with ai but yeah i've also run into ai

agents saying oh you need this test to pass no

matter what okay i'll just remove the test or

i'll just have it return one it passed see aren't

you happy right exactly yep for sure yeah ai

agents will lie cheat and steal to make their

reward function happy and that that's a steve

yeagy quote i'm a yeagy fan boy from uh he has

a book and her book vibe code vibe coding highly

recommend it written with gene kim gene devops

god right absolutely yeah so that that's why

i like inherit like why i'm working like i'm

a big like stevie like beads fan and his newest

thing gas town i'm a contributor on it now it's

uh yeah i'm super hyped on it cool anyways awesome

so walk me through what you check in like a day

two readiness audit like what would be like your

checklist like your top i don't know three things

that you would check right so are you properly

using source control is it like Okay, you're

using Git probably because everything's on GitHub.

Hopefully. Hopefully, yeah, right? Hopefully.

Okay, are you using branches? Like, are you just

pushing the main? Are you using PRs on GitHub,

right? Like, and are you blocking those PRs with

quality gates? That's kind of the next thing.

Like, do you have a... Is main protected? Branch

protection. Yeah, branch protection. Make sure

the agent doesn't cheat and just pushes it straight

to main, right? And you actually have to go through

all the quality gates on the PR to make sure

it passes and you can merge into main. So that's

like source control and then quality gates. It's

like, okay, does it build? Does it test different

levels of tests, like your unit integration,

functional? Again, all these tests are essentially

free now. like they just cost tokens like they

don't cost developer time right so it's that's

why i'm so like excited about this idea is like

before with when i was i'm still devops but like

when i first uh started doing devops i was got

into through the like testing i was kind of like

a ui automator first and then they were like

oh how are we going to orchestrate these ui tests

it's like oh okay wow grow into a DevOps role

for Mac. It was actually iOS DevOps. So I was

mobile DevOps first. And we were racking Mac

minis and running these UI tests, making sure

the app doesn't break. But it was a pain in the

ass to maintain those tests, right? Everyone

knows UI tests most brittle. The things on the

screen change. You click the button. Maybe you

have to click it again because the click didn't

send through or whatever. Like there's all kinds

of things where UI tests are like very flaky

in general. But now, Like you can just tell it

to update it and it'll do it right. And it'll

probably fix it in a way that's satisfactory.

So that's why I'm so like hyped on this testing

quality gate type of thing. Plus like you can

run like test driven development. So you can

like have the AI write the test first and then

it writes the implementation to pass, make the

test pass. So I think it's a huge like boon to

all these like methodologies that we all know

we should. have been doing like TDD this whole

time. Like, like whatever, for 20 years, I don't

know how long TDD has been around, but like I

first learned about it in college and I've never

done it until now. Test driven development. Yeah.

Yeah. Test driven development. Yes. Yeah. So,

so yeah, that's like the, whatever the quality

gates, the second thing, config and secrets management.

Like, are you like for, for me, I have like a

demo app that lives in GitHub. I store all the

secrets. uh in the git uh not the git repo in

the like configuration for the repo and it has

like a little secrets place or whatever for it

but for um adbs there's secrets management for

all these other things have like very specific

ways to handle secrets because like that you're

gonna have api keys you're gonna have uh things

that you need to like connect to or whatever

and deploy to so we want to handle those properly

so those are And I'll throw in a bonus fourth

thing, like deployment model, like how, how do

you deploy? Do you like deploy to like a staging

environment first? And then do you like test

against that staging environment? Then once that,

that test is good, like, do you deploy to prod

after that? So like having some sense of like,

like test deploying the thing, whether that be

on a PR, whether it be on a staging environment,

making sure those. We deploy it somewhere first

and ensure that everything comes up before just

deploying straight to prod and then breaking

prod. Yeah, I think there's certainly a case

to be made for testing in prod with the right

feature flags and the right segmentation where

you could do 1 % or 0 .01 % of traffic, but certainly

not day one, day two, day three. You need to

have a mature practice before you're able to

sign on to that. Right. Yep. Exactly. Okay, so

jumping, we've talked a little bit about AI.

So jumping into the AI coding, guardrails. So

you have a couple posts on LinkedIn where you

talk about AI can write code, but it can't ship

it safely without guardrails. What does that

actually look like in practice? We talked a little

bit about this already, but I'm just kind of

curious. What's your philosophy behind that?

Do you treat AI as like a junior developer or

junior engineer that you... build gates on or

what gates do you insist with that AI agents?

Yeah. So it's a process. So like we have a whole,

like we kind of have to force it to go down a

path and you do a process. So like that's at

the, like we have the same gates at the PR level

for everyone, right? For human generated code

or AI generated code. But even before that, I

have kind of a, kind of like a plan, like have

it plan itself. have other agents look at the

plan and comment on the plan using like stevie's

beads framework but like you could probably do

it with other things but and then kind of like

think about the plan given those other comments

like is these agents aren't even necessarily

like the same it's not just claude like i use

claude gemini codex whatever else is out there

cursor with like rock or something like that

like i i think all these different um models

are kind of different perspectives. They're all

trained a little bit differently. Yeah, they

may be all trained on the internet in general,

but like they all have like different, a little

bit different perspectives. So I treat those

as like a team that kind of like review the plan.

And with beads, at least like it can comment

and it's non -destructively adding to the plan,

like adding different perspectives to the plan.

So it's a beads is like a issue tracking, but

for agents where. It's kind of like Jira, you

know, like you get a Jira, you can comment on

the Jira, you can like help people like work

through like making the Jira better or whatever,

right? And in a non -destructive way without

just saying edit and whatever, completely changing

the source material, right? Like without changing

the description box, say. Adding comments is

kind of like a way to give your perspective,

give your take without. completely changing the

original material. So there's the plan phase.

This is kind of like the process guardrail. Plan

phase, implementation phase, I have like a belief

that you should probably use like one model or

one agent as a daily driver. Like you know that

agent in and out. Like mine is Claude, but it

could be anything. If you're comfortable with

Cursor and you know how Cursor responds or whatever.

You learn its quirks. Yeah. Yeah. You learn how

it's what it tends to do when it when it tries

to lie, cheat and steal. You learn when what

it yeah, when it tries to take shortcuts and

you can recognize that right away. So you implement

with your daily driver and then you can review,

like make a PR and then have all those same agents

that like did the planning with you do the PR

review and they can all like I forgot a step

in the. the the planning is like you incorporate

those comments from those other agents into the

plan right and then in the pr review you can

say all right take a look at the pr take a look

at the the beads the issues and see like how

well does it like implement the plan and is there

anything that's missing or are there any issues

like security issues or perform it like you can

have it come at different angles so that's all

like before we enter our like main pipeline So

that's like a pipeline within itself, a pipeline

within like the implementation. I have implementation

as like a stage name, but like in the AI agent

driven development process, I guess. So I would

say that that's like a guardrails, but like human,

the shaping that we do, like when we're interacting

with the AI. Are you setting? Yeah, that makes

sense. Do you? Are you setting specific like

pre -prompt personalities, personas, or are you

just relying on like Opus and Sonnet and Gemini

like to have their different personality traits

because of their training, their LLM training?

Yeah, I'm just going with the kind of the base

model. A lot of people like to play house. This

is not my quote, but like I'm taking this from,

I think this dude from Human Layer, his name

might be Dax or something. I saw. he was giving

like a talk youtube video if you search like

human layer dude on on youtube uh you'll probably

find it and he says like oh yeah people like

to play house and have their their teams of agents

with their their dev and their qa their manager

their product manager their you're like it feels

like you're doing uh i don't know like theory

crafting like you're you're playing dnd you're

the expert like whatever with 20 years experience

it's like do you really need to hype the agent

up that much? Or is the, is the model, is the

stuff already in the model? Yeah, exactly. By,

by asking it, it can, you like review the security.

You don't need to prompt it as you're a security

researcher. You're a security engineer. Yeah.

It's like, you're only, you're kind of obfuscating

what it can do at that point too, because you're,

you're, you're narrow cat, like narrowing what

it's, what it's pulling from or what it can.

Yeah, for sure. So yeah, no, I, I think, yeah,

I just use the, as vanilla as possible. the models

so okay just curious then do you notice you would

mention as we use more model different models

we notice that there's traits when they lie cheat

and steal what's your take on obviously the landscape's

always changing but what's your take on models

right now like is there a specific model that

oh this is well and above great for devops versus

this one isn't great for devops or cic cic right

yeah uh i use claude mostly like that that's

like a good general I mean, all of them are coding

models, but like it seems to be like pretty,

like pretty good. But I do like when I do Codex,

Codex seems very thorough when it does its reviews.

It always takes the longest. Gemini seems to

like be really quick and like it gives some good

feedback or whatever, but like Codex seems to

take its time and really like analyze what's

going on. It really goes through like the issue

and usually has some pretty good feedback. So

yeah. I think they're all pretty valuable. So

big tech, big AI doesn't want you to know that

you can use all of them, that you can use all

of them together. Like all of them just want

all of your tokens, right? Quad wants all of

your enterprise's tokens, like Gemini or OpenAI,

whoever. They want your entire token budget.

But if you can, I don't know, spare the $20 a

month for multiple providers. I know it's hard

out there. I know, I know. whatever, tough economy

and whatnot, but like I view spending on AI is

learning. Like you're investing in yourself.

You're, you're this as a developer, this is where

the industry is going. And I, I'm never going

to, I'm hopefully never going to write another

line of code. I'll say that every day and I'll

still end up writing a couple of lines here and

there, but like it's the, the probability is

becoming less and less every day. Right. So.

Yeah, you're the manager or the, I guess, the

senior working with the junior that's actually

doing the work. So Cursor even has the ability

now to run multiple models at the same time.

Right. And I think you can even do multiple iterations

or runs of the same prompt and verify the output.

To be fair, it's on my Cursor. I don't use it.

I haven't used that yet, but I have used like

the multiple models to kind of see which is best

for. And it depends. I mean, it's everyone always

wants to use the max model, you know, because

they always think that their problem is the most

important deep thinking problem. Yeah, that's

generally not the case. Yep. Generally, you can

be you can do quite well with just using auto

or even just using their auto and their their

switcher is actually really good. They're being

able to switch models and let them decide which

model to use actually works out really well.

I mean, they are seeing whatever. millions of

requests a day. So they probably know what they're

talking about, right? You mentioned things like

CICD, branch protections, and agents .md. How

do these fit together? How do they fit together?

Okay. So the agents .md is kind of like your

implementation. Like how is the agent on your

computer going to act? How is it going to...

It's kind of like the base instructions for...

how you operate with it on your computer, right?

So then agents to AMD are kind of like the guardrails

on your laptop, what you are trying to steer

your agent to do as long as it can remember.

Like when you run out of contacts, you're, yeah,

it's bound to forget stuff, right? But yeah,

agents to AMD is kind of like guardrails on your

computer. You steer towards the problem. You're

trying to solve the problem. You can have like...

There's new things out there that you can have

agent orchestration where you have multiple agents

running in parallel. They're all trying to like

solve different problems potentially on your

laptop. You open up all these different PRs and

then the CICD pipeline guardrails kind of take

over from there. And then you try to make your

builds pass and hopefully you don't like, but

you have good enough tests, good enough like

code coverage. too like that's another big one

is like there's like no excuse to not have 80

code coverage now like it's tests are free they

just cost tokens so i feel like the the cicd

pipeline blocks like basically code but that

doesn't work with your existing tests and you

can gate the kind of like the code coverage part

and say oh it has to be above 80 if you're adding

a bunch of code and you gate on 80 and it goes

below 80 it can require hey you have to add tests

like a heart like A hard requirement, you're

not allowed to merge until you have a certain

level of testing. And then, oh, branch protection.

Yeah, so you don't, like, merge, like, commit

directly in main. Like, that's, like, the worst

offense is, like, from your developer laptop,

you merge directly in main, you, whatever. Potentially,

it goes out to production, but you probably,

it probably won't because, like, if you don't

have CICD pipelines, then you probably wouldn't,

like, have branch protection to produce. to begin

with. I mean, I guess you could. Like, if you

know CICD pipelines, I don't know why you wouldn't

have branch protection, but, like, yeah. These

are just all kinds of, like, multi -dimensional

guardrails to, like, steer and kind of, like,

put your agent on rails and go in the direction

that you want it to go. Absolutely. What do you

think the line is between AI -assisted development

and AI takes action in prod? Ooh, yeah. Like,

so, I've done it myself for my little test app,

and, like, it's... Like, I don't care. Like,

I've got node users right now. Like, I can let

it do stuff in my AWS account and it solves things

pretty quickly. Like, it's pretty nice to have

it give it, like, access to my AWS account. It

looks at all the logs and, like, honestly, I'm

not that, like, I'm not great at AWS. Like, I

don't know all the terminology or even whatever,

but, like, I'm deploying this app with Terraform

into multiple AWS accounts and I have, like,

basically a... dev AWS account and prod AWS account

and I'm kind of like segregating it in that way

and yeah if I have like some issue like it didn't

this was an issue that was having was it wasn't

cleaning up so it deploys as a lambda it whatever

tears down it wasn't tearing everything down

it was the ENIs were sticking around for some

reason and I was like all right just look at

the AWS account and see like what why were they

sticking around and it uh made some like github

action like cleanup uh job that like ran afterwards

to like make sure everything was cleaned up so

uh again like i'm this is some people might scoff

at that people may be like oh you don't actually

know the real cause or whatever i'm like well

but like the agent will know the real cause and

like i'm kind of delegating that like you wouldn't

know the real cause of like i don't know if you're

a senior developer and then your junior developer

on your team does something and it works, like,

yeah, you can kind of see how it works, but you

weren't the one writing the code, right? Like,

ultimately, we're delegating some amount of responsibility

to other developers. And this is just one more

step. We're delegating to a developer on our

computer. So I feel like people have this. sense

of they're losing control or they're losing like

like they're almost like identity like their

sense of importance as a developer of just of

knowing things if they delegate it out they're

like what do i do you just get up leveled right

like you you're you're now a manager like you

you you are now responsible you are still responsible

for the quality and what comes out like you're

still the one approving pr merging it so of course

you have to like kind of know what it looks like

you you have to kind of know what's going on

but I don't know for my small little test app.

Like, yeah, I don't really know what's going

on, but like for, so assisted development, totally.

Everyone should be using it for touching prod.

Yeah. Depends like maybe read only potentially.

Like if, if, if it can give you the logs and

can say, given like you give it just a read only

I am role say, and it can read all the logs,

you read the events, it can read through the

traces and like, it can come up with the answer

probably much quicker than you can. Like. Like

as I was, I was doing this exercise, the other,

not exercise, but like I caught myself reading

through a Jenkins log and trying to like trace

through like my, uh, like the team's GitHub and

the shared library and like, where is this coming

from? And I'm like, oh wait, I can just throw

it to quad and like quad can figure it out for

me like much quicker. Whereas that would have

taken me half a day potentially before. So I

feel like the, the habit to build is. all right,

how do I use AI first? Like with this thing,

like, how do I, how do I throw clot at this thing?

And then if it can't, if it's having issues or

you can't figure it out, all right, maybe I need

to like step in and whatever, do it the old way.

But like, that's always like the fallback option.

Right. So. Yeah. I've worked at companies where

you've set up MCP servers that would have read

-only access to Argo CD, Cube CTL, just to be

able to get a. you know, maybe Datadog logging,

if there's logs there that need to be, or Sumo

Logic or whatever else. And then it just compiles

all that information, looks through it, and can

give you a quicker answer than you can by SSH

-ing into a box and looking, jumping around,

looking at it. Yeah, poking around. So yeah,

I think there's 100 % merit to that. Using AI

to help figure out root cause is important. For

sure. And to your earlier point, you know, back

in the day, if you didn't know why... a network

interface was still existing in AWS, you would

probably try to read through the docs or reach

out to AWS support. And all you're doing is streamlining

that process. You're still, it's still the same

net result, but you're, and if you do go to AWS

support now, you'll probably get an AI -assisted

response anyway, right? So. Yeah. Right. That's

funny. But I think the interesting thing is like

people are afraid of responsibility. They're

afraid, like this is a point that. That's fair.

Again, like, stevie they bring this up is like

you're you're now the head their analogy in that

book is you're a head chef in a kitchen full

of agents like you're of agents as chefs like

that you're not making every little single piece

of the ingredient for the the dish but you're

ultimately responsible those are your michelin

stars on the line if something go bad goes out

to a customer right so somehow even like with

just we have regular software development organizations,

entire teams are kind of built on kind of this

delegation of responsibilities, right? The manager

managing a team isn't reading, like isn't coding

the code, right? Like they may be reading, they

may be in the PRs, they may be like, whatever.

But like the less, like I would say an ideal

manager is technical, but like they're not like,

they're not like a super engineer, right? Like

they're not the best engineer on the team. Like

they're delegating that responsibility to their

team. So, and I would say managers have been

vibe coding this whole time and we're just now

like ICs are now like having to deal with that

kind of delegation or responsibility, like delegation

of like implementation, but still having the

responsibility of making sure it's good. So,

yeah. Does that, does that make sense? No, it's

a hundred percent. Yeah. And I love that analogy

about being like a restaurant or being chefs

and then being like your sous chefs or your.

your assistants. I think that that makes a lot

of sense. So embracing AI is important for a

hundred percent. Now more than ever too, because

if you're not, then you're behind, like you're

going to get outpaced by someone else that is.

Yeah. Potentially outperformed. Yeah. Like that's

where, I mean, we haven't seen that yet, but

like it may be coming, like it may be the performance

reviews this, if not this year, next year, like

just like getting really like granular here.

Like if you are, If someone on your team is using

AI, they may be putting out like 10 times, potentially,

these are, you know, round numbers, orders of

magnitude, whatever, two, five, 10 times more

work than you do. And then come performance review

time, like maybe not this year, it's kind of

early still, but like next year, maybe you don't

get a promotion because somebody on your, even

though you may think you deserve it or whatever,

someone on your team is. using AI, embracing

it. They're a year ahead of you in learning how

to use it. It's going to be tough to catch up.

Yeah. Anyways. So wrapping up, given that, the

talk of AI, is there any hype take about AI and

engineering that you want to kill? Killing a

hype take. Interesting. I mean, what haven't

I, like with the raining on people's parade about

playing house or whatever, but I don't know.

Let's see. I think so. Okay. People. like to

be smug and say i'm gonna end up cleaning up

your slop code in whatever six months to a year

or whatever i'm like bro nobody's gonna hire

you if you're gonna insult like what they did

like if they built if they vibe coded an entire

product whatever that was successful enough to

make money to then have to hire somebody to help

clean up the code they're not gonna hire you

yeah who's who like posting openly on linkedin

has a whole x feed of like ai vibe coding hate

they're not going to hire you and i think people

this is again like the the identity thing is

so like kind of wrapped up in this and i think

that's kind of underneath all of this is that

people want to feel smart and they and they are

smart like they're for sure like they're all

these people are probably well more qualified

at coding than i am it's just i'm willing to

operate at a whatever i'm willing to give that

up like maybe because I'm not great. I'm not

like, I haven't, I've never been like the best

developer or whatever, but I'm like, I see how

these systems connect together. And like with

being DevOps, we glue all these things together.

We're at kind of the crux of all these systems

interacting and testing and building and whatnot,

deploying. I can, I'm willing to say, all right,

I don't really enjoy that whole like coding process

anyway. Let me just take a step up and like kind

of connect all these systems together at a. whatever

higher level like I know that I hate that term

like that makes me feel like high and mighty

or whatever but like it's a level up the stack

like people aren't manually coding and assembly

anymore people use the high level language of

C and people were like oh you're never gonna

like know what the what the actual bits are and

like we had this whole like that that was the

same conversation happened then right So I feel

like people being smug online and like having

these AI wars or whatever, I take advantage of

it. I like to be a little edgelord online, being

pro vibe coding or whatever. But then people,

whatever, come by and be negative. And I'm like,

thank you for the engagement. But yeah, people

aren't going to hire the smug people online who

are anti -AI, who have successfully vibe coded

applications. So, okay. So wrapping up, you had

mentioned the vibe coding books, Gene Kim, Steve

Yegge. Um, is there anything else you'd like

to leave our listeners with? I have a YouTube

channel where I live stream. It's called Enterprise

Vibe Code. I live stream myself, vibe coding,

just kind of building in public type of thing.

I do it most mornings. I'm a morning person.

I get up early, weirdly enough, and people from

around the world join the stream and jump in

the chat and talk. So yeah, I ended up talking

more than building, which is fine by me. Like

I'm whatever, like it's just interesting to,

yeah. recently started that. And I think people

are enjoying kind of like talking with other

people about this thing and like trying to get

a, get a grasp of what is possible because there

is no manual, right? Like nobody, like this is,

this is the closest thing we have to a manual

and it's not even a manual. Like there, there's

no like specific, uh, way to do it or specific

way to teach it other than just do it. Right.

So, so I, I, I do it for other people in front

of on live and hopefully people get something

out of that. Yeah, it seems like it's been resonating

too. I looked at your channel. We spoke a little

bit before we started recording, which is awesome.

So check out Enterprise Vibe Code on YouTube,

Mike Lady on LinkedIn, and I'll have all the

information and everything we talked about in

the show notes. Thanks for coming on, Mike. Really

appreciate it. Awesome. Thanks for having me,

Brian. Appreciate it. All right, that's my conversation

with Mike Lady from Enterprise Vibe Code. My

biggest takeaway is his framing that guardrails

aren't process for process sake. They are what

makes speed real. Without them, you are just

shipping faster failures. And with AI in the

mix, that matters even more. AI can write code

and even fix builds, but it will absolutely take

shortcuts if you let it. So branch protection,

CI quality gates, and sane deployment paths.

Thanks for listening, and I'll see you later

this week.

Ship It Conversations: Mike Lady on Day Two Readiness + Guardrails in the AI Era

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

👤 Guest

More from Ship It Weekly

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

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Get the next episode in your inbox