A big thank you to Denodo for helping me make
more than 60 monthly interviews possible across
the Tech Talks network. And as businesses move
from gen .ai to agentic .ai, trusted data becomes
everything. Everything from gen .ai to agentic
.ai, Denodo is helping organizations build intelligent,
secure and scalable AI solutions with data access,
governance and explainable results. So, build
AI that you can trust and do it with Denodo.
And you can learn more by simply visiting denodo
.com. What happens when AI starts helping developers
move faster than the business can keep up with?
But most importantly, who carries the can when
the code causes a problem in production? Well
my guest today is the CTO at LaunchDarkly and
he's going to join me in a smart, lively and
very timely conversation and we'll have a little
bit of fun along the way today because we're
going to talk about Shadow AI in DevOps. the
growing use of AI written code and the uncomfortable
questions that many teams are just starting to
ask. And by that I mean everything from public
LLM and unsanctioned coding tools to compliance
headaches, runtime controls, kill switches. Yeah,
we're going to talk about what happens when convenience
meets accountability. And Cameron brings with
him a real world experience, sharp insights and
a few great stories along the way, including
why you can't fire an AI model when things go
wrong. So if your teams are moving fast with
AI or thinking about it, this one will give you
a lot to think and talk about. But enough from
me. Let me introduce you to my guest now. So
thank you for joining me on the podcast today.
Can you tell everyone listening a little about
who you are? and what you do. Sure. I'm Cameron
Ettazadeh. I'm the Chief Technology Officer at
LaunchDarkly, which is a company dedicated to
shipping software quickly and safely. We've been
around for quite a while. We think we're essential
as the AI development lifecycle has reinvigorated
and completely changed the evolution of shipping
software. I've been in this industry for about
30 years, not the industry I intended on showing
up to by any means. I was originally a biochemist
and a chemical engineer, of all things, so I
was off to study medicine, or maybe I jokingly
say I was off to do drugs, as a chemist, but
I ended up in software at Microsoft in the 90s,
worked on Windows 2000. I guarantee most people
in the world have probably used code I've written.
tours at Amazon, Google, IBM, SAP, Ticketmaster
for a little bit, where we did some really interesting
e -commerce stuff. So basically all over the
place. Spent some time as a CIO of a public company
as well. So I like to be able to bring that IT
perspective into what has traditionally been
a product -focused world, because those are our
customers a lot of times. And I've got to ask
the slight gap in your story there tell me about
that pivot that took you from biochemistry into
tech because very often I speak to so many people
on here and there's always a moment of serendipity
or a little nudge from the universe in the right
direction at the right time but what was it that
that made you pivot into tech? You know Microsoft
actually found me now I've been a nerd since
I was a little kid. I grew up, believe it or
not, with some interactions with some famous
AI researchers in the 80s out of MIT. fortunate,
I think I would say, to have had exposure from
a very early age to the Commodore Pets and the
Apple IIs of the world. So it was always something
in the back of my head. And then I ended up working
on some software that did 3D structural modeling
of proteins from x -ray crystallography. And
some folks at Microsoft heard about me in the
90s and just asked me to come out to Seattle
and interview. And I fell in love with a beautiful
city. beautiful greenery and I believe they were
people who were going to change the world. Software
was going to eat the world and it was an exciting
time to be there and we did. Everybody loved
some of the products at the time that we shipped
like Windows XP, Windows 2000, truly game -changing.
pieces. And so my entire career, I've truly tried
to work on things where my passion's been for
changing the game, whether it's how we deliver
software, how we deliver experiences, how we
build for massive planetary scale. It's super
exciting to me. I absolutely love that. Both
you and I have been around long enough to have
seen the early days of the internet, the move
to cloud, the rise of mobile. Then came BYOD,
as everyone wanted to use their own phones and
own iPads in the office. Then came Shadow IT.
Now we've got AI, and most recently of all, it's
Shadow AI now. So from your perspective at launch,
What exactly does Shadow AI look like inside
a modern engineering team? And why is it becoming
such a pressing governance issue for enterprises?
Because many people listening probably would
have seen it on their LinkedIn or in their newsfeed,
but tell me a bit more about that. You know,
I love the fact that people are excited about
this. Change is inevitable. I think we've learned
something in that, you know, this industry as
it reinvents itself has said that Agile was,
in fact, the very manifestation 30, well, 25
years ago, you know, it came back of embracing
change as a true element of the only constant.
Shadow AI is just the modern manifestation of
that. Shadow IT... Long created risks around,
you know, inefficiency, duplicate spend, security
exposures, compliance issues, all of the nasties
that both your corporate legal team and your
CISO and your CIO. all keep, you know, stay up
at night. These were the things when I was a
CIO that gave me heartburn was, I used to joke
I was, you know, one security breach away from
the unemployment line. And I think a lot of CISOs,
CIOs feel that way too, every single day. And
we just see this pattern repeating itself with
AI, especially when developers use public LLMs
and plugins to move faster in the day -to -day
work. I am 100 % for people getting personal
productivity up. getting rid of the drudgery,
the toil. It doesn't do a developer any good
at all to write the same git command 50 times
a day. And in fact, most of them are pretty sloppy
about the comments they put in for their check
-ins. As a good example of that, the AI doesn't
care. It'll write a really nice, clear, concise
statement. Here's the key difference, though.
When you look at Shadow AI, AI is shaping code
and decisions that most of the time go directly
into production. They're not just supporting
workflows. And when you're left without an audit
trail, It's really difficult to explain how something
was built or in many cases who's even accountable
when something breaks a lot of these tools are
moving so fast that There's there's a sort of
missing I'm not going to say regulatory framework
because those exist in many cases are especially
in the EU are starting to really get codified
pretty strongly but from a position of audit
ability From these companies they're ignoring
them. They're just moving so fast that they're
like we'll get to that later And so you get things
like recording tools that don't garner two -party
consent in many places where that's required
For instance or leak internal confidential information,
you know when I cut and paste something Into
my personal chat gpt account and it's got corporate
financial data. Who knows where that's going
to show up We've seen incidents over the last
couple of years, you know, particularly in the
last 12 months where we see corporate secrets
things that are intellectual property that are
hard to protect just leaked out into the public
by Simply asking LM as another character and
and that's really dangerous You know as we look
at IP law protection for instance trade secrets
are the least protected and people are just willy
-nilly Throwing them into production and that
frightens me that's because that's our secret
sauce. That's our competitiveness in this world
as a company Yeah I'm nodding in agreement with
you there and I can almost feel people around
the world watching and listening nodding in agreement
as well and I suspect we've all seen and know
developers that are experimenting at the moment
with tools like publicly accessible LLMs to speed
up coding or decision making and beyond the techies
that every department in every organization are
doing the same thing so where does that line
sit between helpful experimentation wanting to
get involved, excited about the technology and
drifting unwittingly into risky behavior that
could expose organizations to security or compliance
issues? Neil, that's a great question. As I go
back to, you know, my head of security here and
other places, my HR department, like all the
trainings we went through, don't do this, don't,
you know, and we all click through them. Let's
face it. Like these days I just asked Claude
to write a bot to click through for me. I'm going
to read your first to admit it, right? And I'm
sure you do too, right? But we haven't gotten
the message and the training to sink in like
we've done around phishing and we've done around,
you know, other sorts of, you know, harassment
and all these other sort of bad behaviors in
the corporate workforce because it's too new.
I think personally, AI can meaningfully boost
productivity when it's used in a controlled and
transparent way. In fact, we did a study at LaunchDarkly.
We found that 94 % of the teams we surveyed actually
report faster development. But 91 % of them say
they've been more cautious about pushing those
AI accelerated changes into production And that
line is really crossed when developers start
inputting sensitive code or data into tools that
haven't been Approved or secured by the organization
and it's it's to be honest. It's very subtle
Yeah, so you can sit there and say I'm gonna
write a tool that exports data from a and just
moves it to data be in a pipeline You know, we
we do this from our European instance into our
American instance of our data platform for things
that are business critical. And I'm super worried
personally about being GDPR compliant, Dora compliant,
all the things that our European customers expect
of us. But you write a tool and it puts a data
field in there and you didn't analyze that data
field, right? Oh, it works on both sides and
you didn't do that scrutiny. That's really dangerous.
It becomes really risky when these AI generated
outputs are used in production without the proper
review, testing, or understanding of how they
were created. You know more from this survey
like I love the data we gathered here We've got
81 % of the teams that knowingly ship risky code
because of deadline pressures, right? It's that
it's that developer who goes. Yeah, it works
right and they don't know any they don't know
any better They're not being malicious, right?
They're just trying to get their job done. Like
we all want to do every single day 83 % of them
say that the releases containing the AI generated
code are somewhat are very likely to cause those
production issues out there So, you know, it's
a scary time. And if you don't have the visibility
or governance around how these tools are being
used, then this becomes like an immediate compliance
security concern. And we get 38 % of those teams
spending more than a quarter of their time resolving
incidents, which means faster code is not always
more stable code. As an experienced engineering
manager, I think about how teams break down their
work. I want healthy organizations, number one,
because I've worked in some companies where they're
not about healthy organization, and I'm not going
to name names. But I believe in hiring great
people who want to work with me, want to do a
good job, and are dedicated. I assume positive
intent every day. I think as part of that, about
25 % of the work of a team is generally what
I call keep the lights on work. It's bug fixing.
In the US, you don't get a tax credit for this.
You can't get a write -off because it's not risky,
whereas new development work gives you a tax
credit in the US. That 25 % is sort of my bellwether
of is the team moving fast enough or moving too
fast? Because if that's up, let's say it pushes
to 50%, they're throwing stuff into production
that's just unsafe and they're creating their
own problems. And then if it's too little, they're
not moving fast enough at all, which means they're
not really creating what we would call tech debt
over the years. So even with safeguards in place,
like 99 % of teams will tell you they have safeguards.
70 % of those teams still roll back changes at
least weekly, which says there's a huge gap between
protection and real world outcomes. And these
frequent hot fixes are just more or less becoming
the norm now as this code goes ever faster. And
then we hit other bottlenecks, like human scale
bottlenecks, like reviewing the code, analyzing
what's going on, debugging. A lot of that's still
happening at human scale. So I think what I would
take away from that is a lot of people are saying
software's free now. Code generation has made
software free. And that's not true. Software
has made code generation free, but all of the
day two behaviors around that and the validations
and the verifications, that stuff still exists.
It still takes time and now all you've done is,
if I'm going to borrow the work of Eli Goldratt,
you've moved the bottleneck in the pipeline.
I love the goal. It's one of my favorite books
of the last 40 years, I think. And you made such
a good point there as well about the pressure
that developers are feeling. I mean, it was,
I don't know if you saw the viral video recently
of Jensen Huang talking about, he'll be measuring
performance by how many tokens the team are burning.
And if they're not burning that much, they might
appear on a radar. Did you see that? What did
you take away from that? You know, we had our
board meeting. last week and we were talking
about this with the board and they're asking
me too, what do I look at? How am I measuring
developer productivity? There are companies out
there, and this is not anything I'm measuring
internally to be clear, but there are companies
out there that expect to spend two times a developer's
base salary in tokens per developer per year.
Wow. So if I have a, let's just say a $300 ,000
Silicon Valley, you know, mid level developer
base salary, you know, somewhere in that range,
right. They expect to spend $600 ,000 a year
on tokens for that guy or girl. Right. That's
crazy to me. Cause are you really getting the
productivity out of that at the other end? Yeah.
And you know, what I'm seeing here is you're
getting the productivity, but you're getting
the rework that goes with it. And that to me
is, is, you know, if you go back to lean, it's
waste. Yeah, in the process. Yeah, 100 % with
you. And another stat I read elsewhere recently
was that 70 % of teams are now using shadow AI
tools to get work done. I mean, that just shows
you the scale of what we're talking about here.
But when teams are using unsanctioned AI tools
without clear oversight. Organizations obviously
can lose visibility into how decisions are being
made or how code is generated. But what kind
of risks does that create for engineering teams,
especially when they're on no audit trails, runtime
controls, or clear ownership of the final output?
The me of 20 years ago finds that stuff quite
scary, that all that stuff's missing. But tell
me more about what you're seeing here. I get
to be a little snarky because my mother and her
family grew up in New York, so I get that little
bit of underlying sarcasm in how I look at things.
You can't fire Neil an AI model. You just can't.
I can fire a human. That's the snarky way of
saying it. But what it really boils down to is
it creates an accountability gap. To be blunt,
I don't want to fire a human. I value the hard
work my folks put in and everywhere I've been,
it's been that way. But you can't have an accountability
gap in a healthy organization. And it didn't
matter. Before we had AI in the organization,
there were a lot of organizations that had no
accountability. And this is where the business
starts to falter. But with this, it gets even
more critical. Teams can't trace who made a decision.
They can't trace how output was generated. In
the context of the EU AI Act, for instance, you
have to have that. That's a huge risk to global
revenues if you don't have that kind of traceability
and that decisioning. And it's really hard to
justify decisions around compliance, instant
response, and to be honest, the most important
thing, which is customer trust in a business.
And then you get a security risk. You don't know
where these tools are coming from. We're seeing
poisoning events in some of these LLMs and some
of these repos, open source repos out there that
are coming about from this. If there's vulnerabilities
that are introduced because this version got
pulled down by an LLM and nobody checked it,
it just works, right? It goes and selects the
best tool it thinks it has. There's no clear
understanding of those origins. That's a huge
risk to my business and to my customer's business.
I say honestly to my folks, I don't care if we
leak our data as much as I don't ever want to
leak my customers' data because I value that
trust and that reputation more than I even value
my own business because that's what we stand
for. Without runtime controls, you get very flawed
or very risky AI -generated code that goes to
production unchecked at a prodigious rate that
we've never seen before. And four and a half
thousand miles away from you on the other side
of the pond here, the EU AI Act is beginning
to move and especially go from discussion to
implementation. So how does Shadow AI complicate
compliance for organisations that are operating
here in the UK where I am and indeed across Europe?
How do you see this evolving? I think it's really
interesting. You guys got, you guys, I mean,
I say you guys, but we sell in Europe, so we're
there too. Let's be, let's be blind. We've got
a couple of big deadlines to come up, right?
The next one I think is early August, right?
The second this year where there's a majority
of those rules coming into force, including rules
for super high risk AI systems under Annex 3,
which are the transparency obligations. And then,
all the full enforcement, and you've got to get
these regulatory sandboxes, there's a lot of
dates driving that roadmap. But it boils down
to that transparency, traceability, and accountability,
and all of that breaks down with Shadow AI. If
you don't get visibility into those decisions
that are being made, how are you going to have
those high -risk compliance? How do you know
you're in compliance with those high -risk actions?
I think when most organizations come in and they
start evaluating the risk classification across
their organization, they're shocked. Actually,
I'm American, I can make the joke of shock and
awe. They have shock and awe at how many things
fall in that high risk category. And then those
fines, that non -compliance risk just goes through
the roof with legal exposure and pretty hefty.
I think, you know, everybody should be aware
of what falls in that high -risk commercially
relevant bucket, which is anybody using AI to
screen, rank, match candidates, AI for credit
scoring, for education, for critical infrastructure,
law enforcement, health care. This is that full
compliance regime. And so I'm looking to build
systems around that and help folks manage risk.
And I can't manage it up front. I'm not a frontier
model builder, in some ways, thank goodness.
I'm not a frontier model builder. Because then
I would have been under this months, years ago,
two years ago, I think. But my goal is when you
discover something, let's help correct it. Let's
shut it off right away. Let's get the remediation
in place. So one of the things I actually like,
and I've been around I lived in Europe for a
while in the Nordics in Stockholm. So I'm familiar
with the climate. One of the things I really
like about this law is they're really about shepherding
you toward compliance. If you sign up, you sign
the compliance pledge, you do all of that, then
they're more focused on remediation and getting
this right. So the use of AI is healthy versus
punitive. And I think, while the fines are large
and scary, I think the push is generally in the
right direction for how do we use this safely
so it benefits everybody that we're doing business
with. And so I admire that. In the U .S., we're
still dealing with a patchwork quilt of laws,
a Congress that's struggling to make sense of
it, and various states, they're like, we can't
wait that long to protect our folks from the
use of this technology. And it's powerful. hidden
bias, the amount of inference it can make through
pattern matching across a data set that even
the best of us could ever hope to keep in our
heads. It's dramatic. And so I respect their
attempt to try to bring some kind of sanity and
some kind of security to it so that we can all
benefit. This is a positive use of AI, but it's
a lot of work. It really is adding another layer
of complexity with the EU product liability directive
and on that side of things a question I've got
to ask you here is if an AI coding assistant
may be introduced a vulnerability that later
leads to a breach or regulatory failure where
does the liability realistically sit in this
kind of situation? Yeah, I mean that liability
remains with the organization deploying the code
This is the this is the companion piece to that
AI AI act, you know in some ways It's even the
sharper commercial risk AI act tells you here's
what I'm gonna build Here's how I'm going to
govern it and this PLD tells you exactly what
happens when something goes awry, you know, you're
now Let me say this before I say that like we've
talked for years about how software is a factory
Right Agile was a great, you know, I mean not
that I necessarily subscribed to everything Kent
Beck and and and folks like but to but Agile
was really turning it into the factory What's
that pipeline? Right and then you got folks like
Gene Kim who came in with his brilliant book
The Phoenix Project You know, which was which
was a lot of that theory of constraints that
he like old rat put out there This turns turns
you know this law explicitly says essentially
if you're producing software you are now a manufacturer
in the legal sense and the legal protections
that software companies historically enjoyed
the ambiguity about whether software was really
even a product a high burden on the plaintiffs
limited damages those have all been systemically
dismantled so any failures here point to gaps
in governance testing and oversight not just
tool usage We get a lot of questions around due
diligence then, right? And so you want to go
in your organization and look at, were you healthy
about, are these tools approved? Are they understood?
Are they used within clear guard rails even,
right? It doesn't shift responsibility at all.
In fact, if anything, it increases the need for
strong controls. I think a lot of us in, you
know, in engineering, a lot of us who have grown
up with this technology forward bent of always
just being a builder that's frustrating for us
because it feels like we're pulling the brakes
on something that's intended to help us go faster
right it's almost like you're you're getting
in your your sports car you know and flooring
it and and the guy in the in I was about to say
the right seat but the left seat in your case,
right? Still got his hand on the parking brake.
Yeah, it certainly feels that way sometimes.
And then if we also look at the traditional IT
governance models that we were both seeing since
the start of our careers, they were designed
for software built and deployed by human teams.
But those models are obviously going to struggle
when AI systems and AI generated code become
part of the development workflow too, right?
What are you seeing here? You know, we ran a
really interesting experiment the other day.
One of my teams, I'm gonna give one of my wonderful
engineering managers, Carmen Kwan, a shout out
for doing it. She was amazing. She ran a bug,
we called it bug day. And so it was a bug bash
and you've done these forever. But we did it
all with tools. And we did it all without the
engineers actually writing the code, but prompting
the tools with a lot of human oversight. And
what we discovered, it wasn't surprising to me,
but it just reinforced it, which is all of these
processes are designed for deterministic human
-driven systems where the risks are visible and
contained. And the bottleneck, again, just shifted.
It became reviewing and oversight of these systems.
So we've always placed the focus on things like
pre -deployment checks, which assumes human ownership
of decisions. And all of a sudden, AI is introducing
non -deterministic behavior and logic within
workflows, often without clear ownership. In
fact, the reason we like AI, the reason we enjoy
interacting with it is it's somewhat random.
There's a temperature baked into a model, which
is exactly how random this thing is. I say random
because this is a math, right? It's a bunch of
matrix multiplies. But some people would say
the... Creativity, which I think I don't like
to anthropomorphize AI personally, but I get
it, right? We like that as a human. That's the
part of being human. All of us who've been in
this industry for a long time probably went into
it because we like determinism. The machine does
exactly what I said it did, unless somebody else
broke it and put a bug in. And I think part of
our business in LaunchDarkly with these runtime
controls and checks is about bringing predictability
and determinism to a probabilistic system by
putting guardrails in place that create, I mean,
I'm gonna say this, I'm not gonna create stochastic
processes that are repeatable by nudging things
back on course or course correcting along the
way. So it takes that creativity, leaves it there
and helps bring it back to steer to the outcomes
you want. You know, this requires ongoing real
-time control. So monitoring, guardrails, rollback,
kill switches, et cetera, and not just approval
processes in there. It's not about saying, yes,
this is good to go. In fact, I can get another
LLM to do that, and then what do I need to be
around for it? But I want to be able to shut
this thing off when it goes haywire. And it doesn't
necessarily even go haywire, Neil, because...
you know, I made a logic error or the AI made
a logic error. Sometimes it goes viral and all
of a sudden I'm burning tokens because I don't
know if you saw the Chipotle meme last week where
they were used. Last week, week before, someone
discovered that the Chipotle chat bot could write
Python for you instead of making your burrito
bowl. So it was super interesting. I'm like,
why pay for a clogged subscription when I could
get Chipotle to do it for me? Yeah, I mean it's
a you know these it was never intentional But
you'd want to shut that off and in you know 200
milliseconds or less, please So, you know governance
the point that I'm getting at though is right
is governance has to evolve right? It's no longer
static approval But it changes into continuous
control embedded in your delivery systems I think
the best organizations Did this in the move to
the cloud they went from static audits? and static
remediations to things like in an AWS ecosystem,
for instance, looking at CloudTrail CloudWatch,
putting lambdas in to remediate security issues
in real time. And so your check was that this
lambda fire when I unencrypted an S3 bucket and
force it back to encryption, instead of checking,
are all my buckets encrypted? I think AI is the
same way. And so the best organizations that
are going to function and make use of this technology
in a safe way, have those automated remediations
and automated feature flags and automated kill
switches. Internally here, we're doing a project
internally where all of our PRs are automatically
examined by an LLM. They're wrapped in feature
flags before they go into production. There's
observability data created as part of this process.
So that's a huge augmentation. The things we
would teach a developer how to go from a computer
scientist to a software engineer, because the
two are very different in my opinion. Moving
from computer science to software engineers,
learning about how do I do day two? Day one they
teach in school, how do I write code? Day two
is how do I actually make this work for the 54
trillion flag evaluations that we're doing every
single day across the planet? And that's a learning
curve. And now we've been able to help augment
that with the use of these tools to say, these
are the behaviors that we codify in our organization
that we've learned through years of operating
experience. This is gonna help teach you how
to do that or do it for you on day one. And I
always try and give everyone listening a few
valuable takeaways. So from a technical perspective,
how can somebody listening in their organization
better increase visibility into how those AI
tools are being used inside live systems? So
they can maintain that element of control, but
doing so without slowing innovation. And I understand
it is a notoriously tricky balance, but any tips
or advice on how to do that? AI moves faster
than human scale. This is scary to a lot of people,
because I've never been on a hamster wheel and
run this fast in my life, and felt like I wasn't
moving around the cage. We're in an arms race,
and I don't use that term lightly. I'm very,
very protective of it, but I think this is a
true arms race that you're not going to be able
to get out of. And so the way that you win that
is you make AI usage visible by design across
the development lifecycle. And I think there
are a lot of small companies out there trying
to get audit trails in place for their usage
where it's not just the outcomes, right? We get,
every time it checks into GitHub, like I get
a history of what went in there, but it's understanding
the why of how those decisions were made. you
have to embed governance and controls directly
into the delivery workflow. So all of these AI
-generated changes are tracked and reviewed,
and the attribution to the author has to happen
in there. And it's nice. Like, one of my projects
here right now is, what does our internal development
platform look like in a year? How do we enable
developers so this stuff is baked in there so
they don't have to think about it? They just
have to do. You need to have incredibly good
runtime observability for this to work. You have
to monitor how these AI influence features behave
in production. In light of our EU AI laws that
we were talking about a minute ago, that's even
more important that you use techniques and software
packages to monitor how these are behaving in
production so that when it comes down to defending
yourself, you have a commercially reasonable
answer to. I did what was, I tried to do the
right thing here and if we broke it, we can correct
it. But we did everything in our power to figure
out that it was the right answer. You need guardrails
as well, approval layers, policy enforcement,
restrictions on sensitive data. So your internal
data classifications and governance become even
more important and especially when you're running.
you know, data lakes or, you know, modern companies
don't even run data lakes anymore, right? We
run data fabrics where data is a product that
your individual departments or services or products
actually just vend internally. Now you have a
distributed governance project or problem to
deal with. And so how do you classify, protect
that, put the guardrails in place? So, you know,
my LLMs, my agents here, every morning I run
agents. I'm sure you do too, Neil, at this point,
right? My agents come through my emails for me.
They go through my daily schedule. They do all
this and they have some pretty pretty privileged
access. It's not like Let's be clear. I'm not
an open claw like Just YOLO the world, right?
You can have my checkbook my Amazon account,
please have it all No, but in a more serious
way though, it does have access to some of the
things with the minimum spanning set of permissions
I could come up with, but it still needs some
sorts of privileged access. I just have audit
trails on it. And we want to make sure that there's
policy enforcement restrictions. There's a governance
process. So as I build these, as my engineers
build these, A lot of them are skills internally
and we review them together and then we share
them so that you don't have to have somebody
else take another attempt at rewriting it as
easy as it is and maybe get the security permissions
wrong. And people are grateful for that. We're
sharing best practices, we're sharing research
tools, we're sharing all of our internal operating
agents. And there's a couple hundred to a thousand
already running around here. They're all... They're
governed, right? There's a check in an audit
trail and people are constantly looking at them.
And then the last bit of this is you've got to
ensure that there's rollback mechanisms and kill
switches, runtime kill switches, flags around
that to defend yourself and really gain control
when issues arise. And those issues could be
costing, they could be fairness, they could be
the jailbreaking of coding Python instead of
making burritos. You want to make sure that as
you have probabilistic behavior that is, I mean,
non -deterministic behavior, really, that if
you don't like how it's behaving, you shut it
off. It's like, in some cases, it's like, you
know, taking your toddler out of the classroom
and giving them a timeout once in a while, but
you got to be able to reach in there and do it.
Hopefully we do it before they're all sentient,
right? No one shut me off? I'm sorry Dave, I
can't do that. Yes, I was going to say it was
getting flashbacks of HAL in 2001 there. And
finally, before I let you go, four boards, CISOs,
DevOps and other leaders that are listening today
around the world. What questions should they
be asking right now about AI governance, accountability,
et cetera, to avoid security compliance and liability
exposure in the years ahead? Because right now
everyone's excited about the new tools, et cetera.
But the so -called boring stuff, the important
things that could bite you later on is very real,
that threat is. So any advice there? Yeah. Are
they asking you or are they going to ask Claude?
I'm kidding on that one. Look, it's a really
good question. This comes down in my not so humble
opinion to the difference between wisdom and
knowledge, which is you need to have the experience
and the wisdom to really raise this at the senior
level and say, number one, do I have visibility
into where AI is being used across our teams?
And I think if you spend some time and just ideate
on this, be curious about it, ask the questions,
you're gonna find it's used everywhere. Everybody's
got the, I don't know, what are we calling it?
It's the little star, right? I forget, what are
we calling it in the industry now? I've even
forgotten. The AI token in the corner there that
just blips. Everything has it now. So you say,
well, you know, I'm not using it to write my...
you know, spreadsheet or whatever. Oh, yeah,
you are. It's absolutely there. So I think you'll
be surprised. I think the next question you want
to ask is who is ultimately accountable for the
AI generated outputs? And how do you how do you
create the attribution back to that person? The
next question is, can we trace and explain those
decisions or code if we if we needed? And I know
our chief legal officers definitely want to see
that. But even as an engineering manager, I want
to do that because it helps me make the architectural
decisions about how my product looks and grows
and helps make the business decisions of these
are the two use cases and we have to pick a path.
The next question is, of course, do we have runtime
controls like rollback or kill switches in place?
That's absolutely critical to be able to make
split -second decisions. Code still takes time
to ship. putting it out there, enabling it in
production with runtime controls is all the more
valuable. You can't just ship forward or roll
back. You have to have a runtime kill switch
in place. Are my teams using AI within the approved
guardrails, especially with the sensitive data
and how am I protecting that data? We're doing
all of the typical endpoint threat detection
and response on our machines here like you would
do. And we're watching who's connecting and how
they're connecting to some of these services.
And we do it not because I don't want people
to use it, but because I want them to use it.
govern through our corporate, you know, our corporate
account with with Anthropic or OpenAI or Gemini
or any of the tools you want versus the personal
account that people were so eager to get started
with. And the benefit is I'll pay for your tokens
internally when you do it, right, which it's
not just stuff isn't cheap. The next question,
of course, is how are we evolving our culture
and bringing people with us to ensure that AI
is being applied responsibly, fairly and with
the right checks in place? And we're, you know,
we're highlighting internally all the great projects
people are doing. We're doing these partnerships
and training. I want everybody to come along.
This is an inevitability. You can't dig your
heels in and be a Luddite for it, whether you
want to or not. As much as I'd love to love to
go back to the days of, you know, walking out
of the office at five o 'clock and shipping on
a floppy disk. It's not going to happen, right?
We're 24 by seven. I mean, and now it's faster.
So. you know, can we bring people with us into
that reality in a way that's comforting to them
and in a way that helps them feel empowered to
be better with these tools and grow. And when
they do, I mean, I'm impressed by every single
engineer in the organization that's shown me
something using these tools where I'm like, that's
really clever. I'm copying that or I'm posting
about that or, you know, and it's great to see.
And then the last question I have is, are we
spending enough tokens on the generative phase
versus inference? And how are we controlling
the costs around this? I think that's a huge
question. I think AI is still in the subsidy
phase. And so there'll be a reckoning where this
stuff gets a lot more expensive in the future.
We're seeing this through rising energy costs.
A lot of arguments, at least here, states that
about who pays for electricity, hardware costs.
And while we still have Processor power and inference
power accelerating right? It's not free in the
in the rare earth minerals that we min mine for
this In the raw resources the land the building
that things that still have to happen to make
it possible I Monitor token spend I monitor AI
based check -ins, but to me they're lagging indicators
of adoption. They're not metrics to optimize
I don't want to ever tell my developer you to
spend two times your salary in in Tokens, please,
wrong incentives, right? That's a perverse set
of incentives for somebody. Just like 80 % of
my check -ins need to be AI. Great, I check in
one line at a time and now my number goes up.
That's not the right answer. The right answer
is measuring the outcomes and measuring the backlog.
I'm gonna say I don't look at backlogs anymore.
We used to say, okay, what's the backlog for
this team of engineers? It's three months, six
months, nine months. It's changed. An engineer
can supervise agent teams. HBR tells me it's
about four is the optimum number of agents to
supervise at any given point in time. Any more
than that, your context switching kind of destroys
your productivity. So my question to my engineers
is are you managing those four agent teams? If
not, why not four, right? And then is the project
that's on the backlog something that has a positive
ROI where the token spend for the outcome and
the time and the context switching has a positive
return for our business some way or another.
And that's all that matters anymore, because
I can do things that I never could do before,
because I wouldn't want to invest 18 months of
engineering time to do it. We had an 18 -month
project here, for instance, we did in eight weeks,
or we're just finishing. And it's going to be
eight weeks for something that would have been
18 months prior to this. And I love it. And the
token spends not cheap. Like I won't tell you
the numbers, but it's a lot cheaper than 18 months
of engineering time that would have done it.
And I love that. I love that change because now
I've gone, I said I was nerdy. I'm not right.
I was always been a theoretician. Like I love
the theoretical. I love the proofs. I love, you
know, spending my time with the journals, reading
the papers. I have to be an experimentalist now.
Because instead of spending a lot of time on
theory, we just try it. And we can measure it
really quickly. We've got runtime controls to
shut it off. And if I throw it away, OK, I spent
a few thousand dollars in tokens to build it,
fine. So change your mindset into being an experimentalist
and forging that path forward by doing. And I
think that's the fundamental shift of what questions
they could be asking. Are you experimenting?
I think when it comes down to it at the end of
the day, Neil. Wow, so much to take away and
think about that. I'd love to invite everyone
listening to share your thoughts on this, your
insights, your experiences. So for everyone listening,
I will post a link to the LaunchDarkly report
that you referenced, I think, earlier in the
conversation. But anywhere else you'd like me
to point, everyone, if they want to connect with
you, your team, or just some of the work and
blogs and everything you write, where would you
like me to point, everyone? So I do tend to post
on LinkedIn fairly frequently. So that's my main
focus. I'm there. I'm easy to find. I've got
a pretty unique name. Drop me a note. Let me
know what you're thinking. Easy for that. And
I'll point you to the LaunchDarkly website. We've
got a free foundation tier that you can sign
up with and play with and see for yourself what
we can do for you. I think it's a neat product
that is all the more important when you have
an AI -driven SDLC for that set of control and
feedback and that loop around releasing, observing,
and iterating with control. I will add links
to everything that you mentioned there. And as
I said, I invite everyone listening and watching
to post your feedback and especially around shadow
AI in DevOps when AI written code could cause
a breach. Who is responsible? This is something
we could debate about for hours. But more than
anything, just thank you for starting this conversation
today. Thanks, Neil, for the time. This has been
great. There was so much to take away from this
conversation today. But for me, I think one of
the biggest takeaways was simple. AI, yep, it's
speeding up software delivery. But, sorry to
be the guy bringing in the bad news here, it
doesn't remove responsibility. If anything, it's
raising the stakes. And yeah, shadow AI might
feel harmless in the moment. A quick shortcut
here, a productivity boost there, a faster way
to get the code out the door on a Friday afternoon.
But without visibility, controls and clear ownership.
All of these shortcuts can get expensive very
quickly. And what I loved about Cameron's perspective
here is that he did not come at this from a place
of fear. He came at it from experience. And the
answer was very clear. It's not a time to panic
or block progress or stifle innovation. It's
simply a time to put the right guardrails in
place so teams, yes, can experiment to their
heart's content. They can ship code. and still
remain in control. So as AI becomes part of the
everyday developer workflow, I think the question
is no longer whether teams will use it. The genie
is out of the bottle now, isn't it? I think the
bigger question is whether your organization
is ready for what comes next. And how are you
managing this transition? As always, techtalksnetwork
.com, you'll find 4 ,000 interviews, lots of
ways of getting in touch with me there. And please,
feedback, I'd love to hear from you. A quick
thank you to NordLayer for supporting the podcast
and helping me make these daily conversations
possible. And if you are listening and you're
responsible for security or IT, you will know
the reality. The reality that most of your risk
now sits inside SaaS apps. and browser activity.
That gap is exactly what NordLayer is addressing
with its new business browser. So instead of
bolting security on from the outside, it builds
it directly into the browser itself. This means
you can control access, monitor activity, enforce
policies and reduce shadow IT all from one single
place. And most importantly, It does it without
adding deployment headaches or complex onboarding.
You get things like browser -based data loss
prevention, SAS access control and zero trust
browsing, but delivered in a way that your team
can actually use. So if you've been trying to
simplify your stack while improving visibility,
please check it out at Nordlayer .com slash browser.
But that's it for today, so time for me to check
out. I'll be back again very soon with another
guest, and hopefully you will meet me here, same
time, same place. Bye for now.