Back to all episodes
Ship It Conversations: Ryan Packer of BambooHR on Why CTOs Are Coding Again, Building a Software Factory, AI Straining CI/CD, Protecting HR Data, Mid-Career and Junior Engineers, and Why Every Engineer Gets a Team of Agents
devopsSREplatform engineeringCI/CDDevOps learningAI agentsAI codingBambooHRengineering leadershipsoftware factory
Explore topics
In this episode, Ryan Packer, CTO of BambooHR, discusses why CTOs are returning to coding and the implications for CI/CD as engineers run fleets of agents.
Ship It Conversations: Ryan Packer of BambooHR on Why CTOs Are Coding Again, Building a Software Factory, AI Straining CI/CD, Protecting HR Data, Mid-Career and Junior Engineers, and Why Every Engineer Gets a Team of Agents
Ship It Weekly
0:00
Current chapter: Cold open
36:49
Chapters
Jump to a section in this episode.
Speed & share
Transcript
Most engineering leaders spent years drifting
further away from the code. My guest today is
a CTO who says he's written more code this year
than in the rest of his career combined. Not
production code for his team, he's built his
own software factory. A customer files a bug,
an agent opens the pull request, tests it, scores
it, and ships it if it passes. At his company,
pull requests are up almost 80% this year, and
quality went up too. But he also says he doesn't
need junior engineers to fix bugs anymore. So
who trains them? 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 month.
To celebrate, through mid-December, you are
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
Ryan Packer, CTO at BambooHR and a former VP
of Engineering at Adobe. Ryan has watched engineering
organizations change from Omniture to Adobe to
BambooHR. And right now, he's writing more code
than he has in years. We talk about why a CTO
building in his own sandbox helps his team and
where it doesn't. What happens to CI/CD when every
engineer is running a fleet of agents? How BambooHR
handles HR and payroll data with AI? What
changes for mid-career and junior engineers?
And why he thinks every engineer will end up
with a team of their own. All right, let's jump in.
Ryan, thank you for joining me. Thank you
so much for having me. Excited to be here. You
spent a lot of your career moving from engineer
into larger and larger leadership roles. Are
you actually writing more code today than you
were like five or 10 years ago? Yeah, absolutely.
I think that's one of the most important changes
for senior engineering leadership. If you think
about it, most of us, whether it's a CTO position
or a VP of engineering position, most of us grew
up writing software. We had done the job of the
people that we're managing. And that's not really
the case anymore. The tools that we're using,
the way that we're building software is totally
different. So I think it's really important for
software leaders to, even though I'm never going
to go back into writing full production code
for my team, it's really important to me that
I'm using the same tools and learning the same
new techniques that they're trying to learn.
So yeah, I've spent more time coding probably
in 2026 than I have in the rest of my career
combined. Awesome. What kind of things are you
working on or coding? A little bit of everything.
I have several different hobby projects that
I will build. Some of the more interesting stuff,
though, is I actually have kind of my own version
of BambooHR, an HRIS system. And so when there
are features and things that I'm interested in,
I'm not necessarily trying to ship them to production,
but I will go in and actually build out features
and functionality in a way that is really incredible
to be able to then share the full vision, rather
than writing a PRD or just sending a Slack message
to somebody like, hey, what about this feature
that I've been thinking about? I can actually
go in and build out the functionality and say,
hey, take a look at this. I know this isn't exactly
how we would do it for Bamboo, but I can convey
fully the ideas through code. And that's incredible.
Where do you think a CTO writing code actually
helps an organization versus where do you feel
like, okay, I need to get out of the way of the
engineers and let them work on this specific
project? Yeah, I think one of the things that
you have to be really careful of as a CTO who's
now jumping in and coding is thinking that you're
doing the same thing that they're doing. Even
though I just said you want to be trying to do
similar things, you want to be using the same
tools, learning the technologies. But you've
got to be honest about the fact that building
the example that I just gave, where I'm building
a feature in my own little sandbox, I don't have
to think about the same level of security, the
same level of scalability. I don't have to think
about a CI/CD pipeline in the same way. I'm trying
to incorporate all of those best practices into
everything that I do. But the reality is the
software that I'm building most of the time is
going to be used by... 5, 10, 20, maybe 100 people
if I'm building something that's kind of interesting
across some subsection of our organization. Whereas
the software that my team is building is going
to be used literally by millions of people. And
the scale is completely different. And so I think
we just have to be careful that we don't come
across, even though we can now build and show
things and turn things around in a really fast
and exciting way, we've got to be really careful
that we don't come across to our teams as thinking
that we're doing the same thing that they're
doing. Okay, you talked a little bit about this,
but I'm curious, are you building things that
are customer focused? Are you building things
that are like internal engineering focused? Is
that a little bit of both? Yeah, a little bit
of everything. I mean, I think at this point,
who hasn't written a recipe application for their
family? So, like, I've done that, too. Like,
I've built the thing that lets my family vote
on what they like to eat and orders the groceries
from Walmart or Costco. So, you know, I've done
stuff like that where it's kind of family-facing.
And then internally, I've built things like,
you know, organization planning in a way that
we would never put into the product. It's very
specific and tailored to my organization, but tools that would allow leaders
to go in and create a hypothesis on what a new
org structure might look like, drag and drop people
around and see what the pros and cons and the
like, how the workload would be distributed, how
it connects to the kind of key areas of of our
source code repository. So things, everything from
kind of internal tooling to small kind of family-facing
apps to prototyping features that would
go out in the product, but I'm not really doing
it for the purpose of prototyping for customers.
It's for the purpose of learning in a common
language and a common experience so that we can
have more rich conversations about how we're
building. And how has that helped you? Have you
noticed a change, like talking with engineering
leaders about like your experience with AI and
how does that translate down to like the individual
ICs? Yeah, I think it has been, for me personally,
it has been game changing because again, the
way that we build software is so different today.
A big portion of our team is really thinking
about, you know, what we would think of as the
software factory, like we're building the factory.
That's as important, if not more important, than
the software that we're producing. The cars,
I use an auto manufacturing metaphor a lot with
my team. The vehicles that are coming off the
assembly line may change and will change quickly.
What's most important to me is getting better
at getting better around how we build. And so
for me to be able to speak credibly to that.
I've built my own kind of software factory. And
again, I know that it's not as big and robust,
scalable, as complex as what we have to build
at BambooHR to scale our overall R&D efforts.
But I know what it means to build software where
a customer can submit a bug in the product that
captures all of the information in the product
that then is automatically picked up by an agent
who creates the PR, who then tests the PR with
various security, performance, all of these things,
scores the PR, and releases it back to production
if it meets certain criteria. So having seen
that process end-to-end, while acknowledging
that it's not the same, it does give you, I think,
a much more credible view on what's possible.
And I hope that's appreciated by my team. You
know, you kind of alluded to this before. There
is a little bit of a double-edged sword. You
don't want to get in the way. You don't want
to come across as thinking that your sandbox
experiments equate to a full blown production
environment. But I think, you know, I hope it
helps me to stay current and to be able to just
understand that I'm struggling. And I guess I'll
say it this way. I hope that my team can see
that I'm struggling to keep up with it all just
as much as they are. Because that's one of the
hardest things right now. The pace of change
is relentless. And there are plenty of days that
I feel completely overwhelmed. If I'm just sitting
back and saying, like, my team's going to figure
that out, I don't feel like I'm in it with them.
And so if nothing else, by being in the trenches
together, learning these new technologies. I
spent the weekend playing with Jev. And, you
know, a week ago, nobody knew what that was.
Every week there's something new, right? And
so I hope it gives me more credibility with my
team. What have you even seen in your organization
as far as how has it changed development or software
engineering in general over the last, like, let's
say three years? Yeah, I mean, three years is
like an eternity these days. I'm measuring time
in like days and weeks. But even since the beginning
of this year, I'll give an example. The number
of pull requests that a team produces is certainly
not the most important metric in the world. And
there are lots of reasons why it's flawed. But
it is a measure of productivity. And as we've
moved to more and more agentic engineering, the
number of PRs has steadily increased throughout
the year. So we're up almost 80% from where
we were at the beginning of the year. So there's
definitely an increase in velocity. Now, the
question you have to ask is, okay, what is that
doing to quality? And so we've invested a lot
in automating as much of the quality process
as well so that we can make sure that we're not
just shipping, you know, AI slop. And, you know,
I'm super excited because the quality by all
of the metrics that we use has gradually improved
throughout the year as well. And so to see both
the increase in output along with, you know,
slight improvements in quality is really exciting.
Now, there are a couple of ways that you can
look at that. One is just you can produce more
features. And, you know, I think there's something
there. There's like every software product in
the world. There's lots more that we want to
do. There's lots that we want to add. I think
the part that is more exciting, though, is we
oftentimes will refer to it as getting more at-bats
with our customers. Being able to go from
an idea to a working customer-facing prototype
in, you know, a day. And then being able to get
the feedback means that the thing that we ultimately
release is better. So even if the number of features
that we released stayed flat, the number of PRs
that actually make it into the production version
of our software, if that stayed flat, I still
am very confident that the quality has gone up.
Not just the, you know... The quality in terms
of number of bugs and defects and those kinds
of things, but the quality of the experience.
How well are we hitting the mark in terms of
getting the right feature for the right customer?
That, to me, is actually the more exciting part.
Yeah, it's not just more features, trying to
actually make sure it's the right features. Internally,
are you noticing more robust CI/CD because platform
teams have this tool now? Are we able to put
more checks in place? How is it helping internally,
on the actual engineering side? Yeah, if I'm
honest on that one, I would say that that has
been more of a challenge than a help. One of
the things, so I've been at Bamboo for about
three and a half years. And one of the things
that surprised me the most when I joined, people
have been talking CI/CD for what, 10, 15, 20 years.
The reality in a lot of the organizations that
I've been a part of, that I've observed, there
are varying degrees of what people mean when
they say, we've got a robust CI/CD pipeline. One
of the things that was really surprising to me
is we were releasing hundreds of times a day
before I ever got here. The number of releases
and the degree to which we had truly a really
robust CI/CD pipeline was, I think, ahead of where
most companies were. And like I said, this was
all before I got here. I can't take any credit
for this. What I've found is that as we have
become more and more agentic, you're starting
to see strain on the CI/CD pipeline and particularly
on test environments, the ability to spin up
enough resources. I think we all know at this
point, one of the most important factors in agents
doing a good job building software is their ability
to go in and test and run that software and
see for themselves, validate themselves. Well, that
requires us to create multiple environments. In
the early days of agentic coding, usually that
looked like every engineer having one or two
environments on their machine. As we scale to
doing more and more in parallel, and every engineer
maybe has, you know, 10, 15, 20, we get to 100, 100
agents working in parallel, having all of those
environments that are able to be spun up really,
really quickly and spun down equally as quickly,
backed with real data, particularly when we're
talking about use cases that really involve large
amounts of customer data, that's not trivial.
And so I would say, you know, I don't want to
sound like I think our CI/CD process has gotten
worse, but I would say AI is definitely challenging
the volume that we can do. And so there's been
a lot of effort to improve the CI/CD pipeline
so that we can scale to the volume of full agentic
engineering. Are there data privacy concerns?
I'm assuming like Bamboo, you guys are dealing
with PII. Is that a concern when using AI? Yeah,
no, it's a huge concern. It's something that
we take really, really seriously. You know, HR
data is some of the most sensitive data out there.
And we also have a payroll product. So thousands
and thousands of people get their paychecks through
us. There's not a lot that's more sensitive than
your direct deposit information for your bank
account. And so having that customer trust, having
a really, really high... premium on security
and data privacy has always been really foundational
to us. We've been really fortunate to build a
brand that people trust over many, many, many
years, but it doesn't take a lot to, you could
lose that trust quickly, I guess. So we, there
are lots of different things that we do, but
first of all, the way that we contract and engage
with each of the frontier labs, we do a lot to
protect the data in that regard. So we're very
careful about what we send to them, and what
terms we agree to with any particular provider
in order to make sure that the obvious things,
of course, that they can't train on our proprietary
data and things like that, but also data retention
policies and those types of things are really
critical. And so we have our AI council that
meets on a regular basis to think through all
of these types of issues that, you know, maybe some of the things that are a challenge
as you adopt AI, but it's a great question because
we need to make sure that that trust stays front
and center for us. Okay. So now I'm curious for
like the senior engineer, if producing code itself
becomes dramatically easier, what actually becomes
more valuable in a senior engineer? Yeah. You
know, first of all, I don't think any of us know
exactly what the world is going to look like
in a few months, let alone a few years, but I'll
pontificate. Um, I have always said the actual
writing of the code has never been the most important
part of an engineer's job. I think the decisions
that we make about what we're going to produce
and how we're going to produce it are absolutely
critical. And so, you know, will AI continue to
to kind of do some of those things? Yeah, I I think
it will. But our role has to be around what is
it that we want to put in front of our customers.
People talk a lot about taste, and I think there's
a lot of validity there. It's kind of become
an overused term, but I do think that there's
still a huge role for people to play in deciding
what to build. And so, okay, there's a lot of
anxiety around like mid-career engineers right
now. Like someone who spent like, let's say like
10 or 20 years getting really good at something
and then AI can like suddenly do it in seconds.
Do you think that that anxiety is justified?
I think it's a really fair question. I definitely
would say that mid-career, I think mid-career
engineers are certainly in facing the hardest
change. I think early career folks, they're at
the beginning. They aren't set in their ways.
They haven't invested a bunch of time and energy
and oftentimes money into learning particular
things. Late career, like, okay, they're late
career. So I understand and I'm really sensitive
and empathetic for folks that are in that middle
portion of their career. What I would say is
this, people who are resilient, people who love
to learn, people who want to do things differently
and are willing to embrace change, I don't think
they have anything to worry about. But that's
hard, and that's not everybody. I think we all
want to say that we embrace change, but like
human nature, we're creatures of comfort, and
change is hard for a lot of us. And so I think
those middle career folks... who are maybe reluctant
to try things differently and are letting a very
realistic fear like, okay, am I going to have
a job? The thing that I'm paid to do can now
be done by AI faster and if not already in the
very near future can be done better by an LLM.
Like, yeah, that's scary. Now, an engineer in
the middle of their career who takes all of the
systems thinking, the design, problem-solving
thinking, takes all of that and learns how to
add LLM and other AI capabilities to it, do I
think they have anything to worry about? I don't.
I'm in the camp of we will continue for the foreseeable
future to need more software, not less software.
And even though AI will dramatically magnify
the amount and the pace of software, there's
still tremendous need for great software engineers.
A good point. Okay, so let's look at the other
side of that. Junior engineers. One thing I keep
coming back to is that a lot of the boring work
AI is eliminating, but it's also the kind of
the work that has taught us how systems behave.
So what happens to junior engineers? Who trains
them? Yeah, I this is this is I'll start by saying
I don't have a great answer. This is something
that I have been thinking about for a couple
of years now. And I remember like even at a really
tactical level, maybe the first thing that a
junior engineer oftentimes does when they join
a new company is you might hand them some bugs
to go investigate. I don't need junior engineers
to go fix bugs anymore. I can, by and large,
have AI go take a look at those things and do
as good a better job. And so I think your point
is a really good one. How do we develop those
engineering skills, if not through the practice
of doing what the AIs have done? And again, I
don't think I have a perfect answer here. Things
that we talk about internally and things that
we're thinking about, there's still plenty of
room for the systems thinking, the designing,
the architecting, and the interaction with the
LLMs can still be really, really instructive.
And so one of the things that I like to talk
about with people that are relatively new to
AI and relatively new to leveraging AI in a professional
setting, make sure you understand what... maybe
not 100% of the time, but make sure that you
take time to understand what the LLM is doing
and why it's doing it. If you completely hand
it over and just say, you know, go do it, you
are limiting yourself in the number of opportunities
that you're going to have to learn. But that's
something that I have loved as I've been building
out software. Are there places where I completely
hand it over to the LLM and just let it go wild
and I'm shipping production code without looking
at it? Yeah, there are. But there are other times
when I'm very intentionally saying, okay, I want
to go learn about this new technology, or I've
seen the LLM do a certain thing 15 different
times. Let's do it again, but this time take
me through it. Tell me why you made this decision.
Tell me why you picked this technology. And I
have found, again, this isn't a novel idea, but
the idea of asking the LLM to confront itself
or creating an adversarial agent to say, come
up with the five things that were done incorrectly
here that you would do differently. Having the
adversarial conversations amongst the agents,
I think is extremely enlightening. Will that
fully close the gap? I don't know. My hope is
those skills, a lot of them will move further
down the stack and we'll be operating at a higher
level and the skills that we need to be successful
will still be there. You'll have engineers that
still want to write compilers and they'll work
with LLMs to write the compilers, but that's
going to be a subset and what they need to learn
is going to be different than the engineer who
is comfortable living at what we now have as
this really, really high-level abstraction layer
of conversational coding. Yeah. Is there something
that you wouldn't hand AI now that maybe you
would in three months? Yeah, that's a great question.
I think the way I think about it is the biggest
changes that I've seen over the last three months
and that I anticipate over the next three months
is kind of the size of work that we can confidently
give to an LLM. So if I go back a full year,
the level that I would specify my intentions,
whether that be in a PRD or a spec, and spec-driven
development was big for a minute, it
was quite granular. I was handing off, okay,
Claude, go work on item 3.4.5. Now I'm saying,
go tackle item 3, that top-level thing, like
the size of the chunk of work that can be done
is just so much larger. I'm sure there are other
ways and types of things that LLMs will continue
to get better at. I am really interested to see
how Jev changes kind of the system one thinking.
Most of the LLMs to date have been really system
two focused. And so to see... how that changes
things. I love the way that that team is talking
about those really fast classification and kind
of data analysis, MapReduce-like functionality.
LLMs have been pretty bad at that, pretty slow,
it's pretty expensive, and you see teams throwing
problems at LLMs because they can, but they're
not particularly good or efficient at that type
of work. You know, it's obviously been out for
less than a week, so it's pretty early to say
that that's going to be the new thing that's
going to change our world. But I'm excited to
see how models like Jev will transform the type
of work that you can hand off to an agent. Yeah,
absolutely. Okay, so extrapolating that out,
I guess, a little bit more. If these tools keep
improving at anything close to the pace that
we're currently at, what does the engineering
organization look like in three or five years?
How does it change? Yeah. I think the main thing
that we see and that we're already starting to
move toward is smaller teams that are then managing
larger groups of agents. So it's a little bit
of an unfair way to think about it, but if we
started out in a world where every engineer had
a tool that helped them a little bit, And then
we kind of move on this journey to every engineer
has a pair programmer that they're working with.
And I think that's where a lot of people actually
live today. I think the future, and we've got
some people that are there and some people that
are still on the journey, is where every engineer
has a team that works for them. And so the role
of a software engineer, kind of across all of
the different disciplines of software engineering,
starts to look a little bit more like the role
of a software engineering manager. They're getting
better at delegating and consuming reports, whatever
that means, from their agentic team so that they
understand how the work is going. They're communicating
more and more with customers. They're communicating
more with their product peers. But we're definitely
bought into the idea of a full-stack developer,
somebody who can think across all of the different
functions. But we're not there today. We have
product designers who are able to pump out incredible
prototypes. And if they ask the LLM to tell them
how to make their prototype more secure, it can
do it. But there's so many questions that we
as engineers have just grown up understanding
that they don't even know to ask. And so I think
we still have a pretty big gap between what the
LLM can do and what it will naturally do. That's
where these kind of full-stack developers will
continue to emerge. We think it starts out more
as a pod. You've got a small team that maybe
has a product manager and a designer and an engineer.
And they're still working together, but they're
able to do what previously a team of maybe 10
to 15 R&D employees would be able to do. So
that's the first thing. I think we see those
teams getting smaller. One of the biggest questions
that we're grappling with is how many people
and agents can you have working in one code base
at a time? And I think that's going to be one
of the scaling limits. So I think, you know,
we've already known that for humans. If you put
300 software engineers on one small area of the
code, it's just not going to be productive. And
we can talk about the mythical man-month and
all those things. But the same thing is true
for agents. The ceiling might be a little bit
higher, but we still have those same challenges.
And so I think a lot of organizations have to
think, okay, do we have opportunities to broaden
the surface area such that we can bring the full
force of agentic engineering to bear? I think
that's where a lot of people get really worried
because they say like, oh, well, I can do the
same amount with less people. Aren't we going
to have to lay off a bunch of people? My supposition
is we're in this really fortunate position where
there is nearly unlimited work to do. There's
so many adjacent areas that we can go into. And
if we're building a culture of incredible engineering,
whether that's using LLMs or anything else, whatever
the technology is to make us efficient, we can
still have a really high ROI on the investment
that we're making in our R&D organization. And
so I actually don't see us shrinking the number
of engineers across BambooHR. If we were to sit
down a year from now, I expect that we would
have the same or more engineers as we do today
because there's just so much opportunity. But
there is this interesting constraint that we're
going through right now where you can't just
throw an unlimited number of agents at the existing
code base and expect to get the full leverage.
That's a good point. Okay, so wrapping up, what's
something about AI or software engineering that
you believe today that you would think a lot
of engineering leaders still get wrong? Oh, gosh.
That's a tough one. Because I tend to think that
most engineering leaders are probably smarter
than I am and are doing it pretty well already.
I do think that there is a reluctance to push
the boundaries of what's possible. I think a lot of us
have grown up in a culture of accountability
and that's great. I think a lot of us are struggling
to fully adopt kind of a non-deterministic workflow.
And so for those of us that are maybe the stereotypical
engineer, the overachieving type A, I want to
build stuff and I want predictable outcomes.
I think it can be difficult to maybe loosen the
reins a little bit. And I'm not saying that people
should go out and immediately turn over their
entire organization to an LLM. But are we creating
enough space within our organizations to have
experimentation that is pushing the boundaries
of what an LLM can do? A lot of times I'll talk
about if every project that we're doing has greater
than 50% chance of success, we're not being
ambitious enough. There's got to be something
in our portfolio that we think only has a 10%
chance of success. And that's where we see
the real breakthroughs and the real changes in
innovation. And so are we giving the LLMs big
enough tasks? Are we turning enough over? Again,
not across the board, not recklessly, not all
at once, but are we creating those areas of real
frontier experimentation to push the limits and
see what's possible? Very well said. Where can
people find out more about BambooHR? Yeah, definitely
check us out on social media. We're on all of
the different social media platforms, but bamboohr.com.
Also, check out the careers page. We're
continuing to hire, looking for great talent,
people that are excited about where this space
is headed. We've got a lot of great opportunities.
Awesome. Ryan, thank you so much for joining
me. Really, really appreciate it. Yeah, thank
you for having me. It was fun. That was my conversation
with Ryan Packer from BambooHR. The biggest
takeaway for me is why a CTO should be coding
again. It's not to ship features. It's to use
the same tools his team is learning. And to show
an idea in working code instead of a PRD. I liked
his software factory framing. The cars coming
off the line will change. What matters is getting
better at getting better. Their pull requests
are up almost 80% this year with quality improving.
But the part he's most excited about is more
at-bats with customers. For the platform folks,
AI is putting real strain on CI/CD. So when every
engineer has 10, 20, or 100 agents going, each
one needs an environment you can spin up fast
with real data and tear down just as fast. On
junior engineers, Ryan doesn't claim a perfect
answer. His advice? Make the LLM explain its
choices instead of handing everything over. And
try an adversarial agent that lists five things
it would have done differently. Last one. If
every project in your portfolio has better than
a 50% chance of success, you are not being ambitious
enough. Put something in there with a 10% chance.
You can find BambooHR at bamboohr.com, including
their careers page, plus Ryan on LinkedIn 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 later this week.
Ship It Conversations: Ryan Packer of BambooHR on…
0:00 / 36:49
Listen & Subscribe
Catch This Episode
Listen on your favorite podcast platform
Commentary
Host Commentary
Notes
Show Notes
This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.
In this Ship It Conversations episode, I talk with Ryan Packer about why a CTO is writing code again, what happens to CI/CD when every engineer runs a fleet of agents, and who trains junior engineers when AI can fix the bugs.
Ryan is the CTO at BambooHR and a former VP of Engineering at Adobe. He's watched engineering organizations change from Omniture to Adobe to BambooHR, and he says he's spent more time coding this year than in the rest of his career combined.
We start with why. Ryan will never write production code for his team again, but he wants to use the same tools and learn the same techniques they're learning, and to show an idea in working code instead of a PRD or a Slack message. He's also honest about the limits: his sandbox serves maybe a hundred people, and his team's software serves millions.
Then we get into the software factory. In Ryan's own version, a customer files a bug, an agent opens the PR, tests it for security and performance, scores it, and ships it if it meets the bar. At BambooHR, pull requests are up almost 80% since the start of the year, and quality has improved by the metrics they track. The part he's most excited about is more at-bats with customers: an idea to a working prototype in a day.
For platform teams, Ryan says AI has been more of a challenge than a help for CI/CD. BambooHR was already releasing hundreds of times a day, but agents do their best work when they can run and test what they build. Ten, twenty or a hundred agents per engineer means environments that spin up and down fast, with real data. We also cover protecting HR and payroll data: terms with the frontier labs, data retention, and an AI council.
On careers, Ryan thinks mid-career engineers face the hardest change, and that the ones who keep learning have little to worry about. On junior engineers, he doesn't claim a perfect answer. He no longer needs them to fix bugs, so he suggests making the LLM explain its choices and using an adversarial agent that lists five things it would have done differently. We finish with every engineer managing a team of agents, small pods doing what 10 to 15 people used to, and why he expects the same or more engineers a year from now.
The big takeaway: if every project in your portfolio has better than a 50% chance of success, you're not being ambitious enough. Put something in there with a 10% chance.
Highlights
- Why a CTO is coding again, and why his sandbox isn't production
- The software factory: a customer bug to an agent PR to a tested release
- Pull requests up almost 80%, with quality improving
- More at-bats with customers: idea to working prototype in a day
- Why AI is straining CI/CD and test environments
- Protecting HR and payroll data while adopting AI
- Junior engineers, adversarial agents and making the LLM explain itself
- Every engineer with a team of agents, and the 10% project
Links
Ryan on LinkedIn · BambooHR · BambooHR careers · More episodes · On Call Brief · LMGT Awards
Guest
BambooHR
Ryan Packer
CTO
Ryan Packer is the CTO at BambooHR and a former VP of Engineering at Adobe. His career runs from Omniture through Adobe to BambooHR, where he's been for about three and a half years.
Made in Greencastle, Pennsylvania
More from Ship It Weekly
All episodes →
Cloudflare Saves 100TB of RAM, AI Drives Server Prices Up, AWS Adds a Fourth London AZ, Route 53 DNS Self-Service, AKS eBPF Routing, Go 1.27, and the Danger of Hidden Infrastructure Assumptions
In this episode, Ship It Weekly discusses Cloudflare's 100TB RAM savings through low-level cache optimizations and the implications of AI-driven price hikes in memory. AWS adds a fourth London Availability Zone, revealing hidden infrastructure assumptions.
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
In this episode, Ned Bellavance discusses the essence of DevOps, emphasizing principles over mere ceremonies. He explores the future of infrastructure as code, Terraform's challenges, and the impact of AI on code generation.
Ship It Conversations: The AI Agent That Ran Terraform Apply, With Davlet Dzhakishev of Cloudgeni on Read-Only Cloud Access, Sandboxes Beyond Docker, Agentic PR Reviews, the Real Cost of Running Agents, FinOps for AI, and Permissions Over Prompts
In this episode, Davlet Dzhakishev discusses the challenges of integrating AI agents into cloud infrastructure, emphasizing the importance of guardrails in architecture.
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
In this episode, Darko Fabijan discusses the challenges of AI-generated code in software delivery, highlighting increased defect rates and the need for automation. He proposes a risk scoring system for changes and advocates for onboarding AI agents similarly to new engineers.
The line I keep coming back to from my conversation with Ryan Packer is "getting better at getting better."
Ryan is the CTO at BambooHR. He came up through Omniture and Adobe, and he told me he's spent more time coding this year than in the rest of his career combined.
That's not the usual direction. Most engineering leaders drift further from the code every year. The calendar fills up, the org grows, and the editor stays closed.
Ryan's reason for going back isn't to ship features. He was clear that he's never going back to writing production code for his team. It's to use the same tools and learn the same techniques his engineers are learning.
His point is that most leaders grew up doing the job of the people they manage. In his words, "that's not really the case anymore." The tools changed underneath us. If you lead engineers and you've never built anything with an agent, you're managing a job you haven't done.
He gets something practical out of it, too. Instead of writing a PRD or sending a Slack message about a feature idea, he builds it in his own sandbox version of BambooHR and says, take a look at this. "I can convey fully the ideas through code."
What I appreciated is that he's honest about the limits.
His sandbox doesn't need the same level of security or scalability, or a CI/CD pipeline in the same way. What he builds might be used by "five, ten, twenty, maybe a hundred people." What his team builds is used "literally by millions of people." The risk is a CTO who thinks his weekend prototype is the same thing his team ships.
He said one more thing I don't hear leaders say out loud. He hopes his team can see he's struggling to keep up just as much as they are. "The pace of change is relentless." I think that matters as much as the credibility he's after. It puts him in the same boat as his team.
The idea that frames the whole conversation is the factory.
Ryan uses an auto manufacturing metaphor with his team. The cars coming off the line will change, and change quickly. The factory that builds them is as important as the software, maybe more. What matters is "getting better at getting better around how we build."
His own small factory works like this: a customer submits a bug, an agent picks it up and creates the PR, the PR gets tested for security and performance, it gets scored, and it goes back to production if it meets the criteria.
He's careful to say it's not as big or as complex as what BambooHR has to run. But having seen it end to end gives him a more credible view of what's possible.
At BambooHR, pull requests are up almost 80% since the start of the year. He knows PR count is a flawed metric, and he said so. The question he asked next is the right one: what is that doing to quality? They invested in automating the quality process so they're not just shipping "AI slop," and by their metrics quality has gradually improved too.
But the part he's most excited about isn't more features. It's more at-bats with customers. Going from an idea to a working, customer-facing prototype in a day, getting feedback, and releasing something better. Even if the number of features stayed flat, he's confident the product would be better.
This next part is the one platform and SRE folks should listen to twice.
I asked if AI was making CI/CD more robust. Ryan's honest answer: it has been "more of a challenge than a help."
That's coming from a company that was releasing hundreds of times a day before he got there. The pipeline wasn't the problem. The volume is.
Agents do their best work when they can run and test what they build and see the result for themselves. Early on, that meant an engineer with one or two environments on their machine. Now picture every engineer running ten, twenty, maybe a hundred agents in parallel, each needing an environment that spins up fast, backed with real data, and tears down just as fast.
My read: if you run a platform team, this is your next capacity problem. Ephemeral environments used to be a nice-to-have for humans. For agents, they're the feedback loop. And with real customer data in the mix, it gets harder, not easier.
That connects to the data question. BambooHR handles HR data and payroll, and as Ryan put it, there's not a lot that's more sensitive than your direct deposit information. Their approach starts with the contracts: what they send to the frontier labs, no training on their proprietary data, and data retention policies. They also have an AI council that meets regularly on these issues. Trust takes years to build and not much to lose.
I asked about the anxiety mid-career engineers are feeling. Ryan thinks they face the hardest change. Early-career folks aren't set in their ways yet, and late-career folks are, well, late career.
His answer for the middle: people who love to learn and are willing to change don't have much to worry about. He's in the camp that we'll need more software, not less.
Then I asked the question I keep coming back to. If AI eliminates the boring work, and the boring work is how we learned how systems behave, who trains junior engineers?
He started with, "I don't have a great answer." I respect that more than a confident one.
He was blunt about the problem, too. He doesn't need junior engineers to fix bugs anymore, because AI can do that as well or better. So the old on-ramp is gone.
What he suggests is being intentional. Don't always hand the work over. Sometimes, ask the LLM to take you through it: why it made this decision, why it picked this technology. And try an adversarial agent: "come up with the five things that were done incorrectly here that you would do differently."
My read: that's a good habit for anyone, not just juniors. The engineers who keep learning will be the ones who keep asking the model why.
Looking ahead, Ryan sees the size of work you can hand an LLM growing fast. A year ago he'd hand off item 3.4.5. Now he says go tackle item three.
Three to five years out, he sees every engineer with a team of agents working for them. The software engineer's job starts to look more like an engineering manager's: delegating, reading reports, talking more with customers and product peers. Small pods of a product manager, a designer and an engineer, doing what 10 to 15 people used to.
The constraint he's watching is how many people and agents can work in one codebase at once. It's the mythical man-month again, with a higher ceiling. And he doesn't see BambooHR shrinking. A year from now, he expects the same number of engineers or more, because there's so much opportunity.
My favorite part came at the end. I asked what engineering leaders still get wrong.
Ryan thinks a lot of us grew up in a culture of accountability and want predictable outcomes, so a non-deterministic workflow is hard to adopt. His fix isn't to hand everything over. It's to make room for experimentation.
"If every project that we're doing has greater than 50% chance of success, we're not being ambitious enough."
Put something in the portfolio with a 10% chance. That's where the breakthroughs come from.
That's the takeaway I'm keeping. Use the tools yourself. Invest in the factory, not just the cars. And leave room for the bet that probably won't work.