# AI-Driven Engineering: Beyond the Pull Request

**Podcast:** Dev Interrupted
**Published:** 2026-07-28

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
Quick thing before we start.
My guest today is Rob Zuber, the CTO of CircleCI, and one of the most familiar voices on this show.
And the idea that stuck with me from our conversation was how the pull request is really starting to feel like a relic.
Because when machines write most of the code and expecting humans to read every line stops scaling.
And Rob's version of the future is a system that tells you what the machines are doing with a high level of accuracy and being a part of the review process with you.
And that's a big part of why Linear B sponsors this show in the first place.
Because, you know, AI is writing the code.
It's piling up.
But the real question is what happens afterwards.
Did it merge or hold up?
Did it move the business and have impact on our users?
These are the questions that Rob is really obsessed with and us too.
And so measuring AI's impact is something that we talk about a lot in this episode.
Here's my conversation with Rob.
I'm really excited to dig in.
I just want to start by introducing Rob Zuber, the CTO at CircleCI.
Now, Rob is basically like...
one of the main protagonists of the Dev-Interrupted Universe, if I were to say so.
He's been on the show a number of times, but also worked with us on a regular cadence to talk about how engineering is getting impacted by AI, how it's really just getting garbled up, just chewed up and spit back out.
totally different.
And I personally always think that Rob is way ahead in terms of the thinking around this stuff.
Like, for example, when I first met Rob back in 2024 at an event we had in San Francisco, you know, he posed a question to the audience.
He said, why are we writing in a programming language designed for humans?
And that really stuck with me.
That was back in 2024.
And now looking at where things are moving in our industry and how fast they're going, it feels like that future.
It's just right around the corner.
So Rob, it's really great to have you back to dive into the latest state of things and to see where your head's at, all this kind of stuff.
Yeah, super excited to be back.
Thanks for having me.
And it's funny that you bring that up.
Like that was a big thing that was on my mind back then.
And I've like totally changed my opinion, but also still reflect on that.
You know what I mean?
Like, so.
I measure most of my learning and development in days or weeks at this point.
So when you talk about a couple of years ago, I do remember that event.
It was super fun.
It's going to be hard to try to map two years.
And I've been at CircleCI coming up on 12 years, I think.
And so it all...
It all feels very linear until the last couple of years where just like everything, you know, started changing so quickly.
And again, as we've been saying, just like for me, that's super interesting and exciting.
And I love learning this stuff and exploring new opportunities.
But at the same time, yeah, trying to remember what I was thinking about two years ago is super.
Well, it'll be fun.
Let's dive in.
I know when we pulled that out of the archives, it's like, wow, just.
how well this question has aged, but also to just like how many questions have now formed between now and then that are still unanswered, that we're still answering.
You know, one of them being, there's this really funny phenomenon in engineering, especially in the last few years around declaring everything dead.
You know, like MCP is dead or, you know, so-and-so is dead.
This is like a thing we love to do.
I get blamed about it all the time as, quote, a tech influencer in the media of dragging these protocols way out to pasture too early and then them ultimately finding their fit later on.
So, you know, in your world right now, what feels dead to you?
What's new?
Are there things in your world that the internet's claiming is dead that you're like, that's so wrong, it's not?
I'm just curious where your head's at.
Yeah.
It's a really fascinating exploration.
Like I think I've heard that CICD is dead.
Our business numbers disagree, I would say.
Like, you know, we're trying to help people deliver high quality software quickly to their customers.
And that goal is not dead.
So the shape will change.
But the idea that CICD is dead, I mean, is we may come out of this with a very different look of how we do that work.
But like I said, like we're, everybody's doing more of it is what, what I'm seeing.
One thing that I like to, I wouldn't say proclaim dead, but I would say it has a target on its back is the pull request.
Because that sort of as, as a form factor, right?
Like the idea that I'm going to get my agent to use a CLI to create a webpage.
It's kind of like PR is basically a webpage that humans are meant to interact on, right?
I mean, I know that you can interact with them so that someone else's agent can use an API to go get the state of that change and write some comments on it so that the original agent or yet another agent can come along and try to react to those comments.
It's a very weird place as an interaction point.
It doesn't make sense in the world that we're trying to transition into.
And sort of, if you go back to that question about, human-oriented programming languages, right?
It makes sense for a minute in a transitional state where we want human inspection to make sure the machines are behaving correctly, but humans were never great at reviewing code to begin with, right?
Pick a PR and give it to the same person on two different days.
give it to the same person at two different times of day based on whether they just ate or just had coffee.
You know, like, are they in the post lunch kind of coma or are they super fired up with a ton of energy?
Are they really interested or do they have five minutes before they have to run to the bus, you know?
And like the quality of that feedback is going to vary so much.
And so that model always felt a little bit broken.
We just didn't feel particularly compelled to do something about it.
But now...
As we talk more and more about shifting bottlenecks in the SDLC and reimagining the whole SDLC, I really think that we will figure out how to do code review, code merging in a way that doesn't really involve a human.
And when that happens, or some tiny fraction of it needs a human, whatever that might be, when that happens, I think that interface is going to feel really clunky to make it happen.
I completely agree about the pull request definitely feeling like a relic of a time where it's served a purpose.
But now almost the pull request is more like a stage than like an office where like the work is happening or people are interacting.
A lot of times now the pull request is like it's a statement of record where a bunch of systems come in and put their stamps on it, good or bad.
Maybe a human's looking at it these days.
Our numbers say they're not.
You dove into those numbers too on our recent, you know, benchmarks report that we had.
And so like you're familiar with how very little human attention is able to get put on the amount of generated code and what goes through the gates that we have.
And so the PR starts to feel a little performative, you know, at that kind of velocity, at that level of detail.
It's also not useful because if I come in and maybe I don't like your PR or your PR is too big or there's ways that we need to change this.
In the olden days.
you'd go and change some lines in that PR.
Now, like you're probably throwing that PR away.
It's just like what you're doing is totally different with the code.
Yeah.
Yeah, I think that's exactly right.
Like the, if you think about a diff even, right?
And how like the presentation of a PR.
So let's pretend for a second that human's going to read it.
The presentation of alphabetical order by sort of tree structure.
of files and then the associated lines in numerical order that have changed within those files, if it's 10 lines of change and you could see it all on the screen, you're like, cool, that makes sense, right?
But when you're talking about what you can easily produce in a small increment of time with an agent today, which therefore feels like a useful unit, right?
Like taking a 2000 line PR and breaking it up into 10 lines at a time is nonsense.
Right.
And then tack on your standard PR delay, which you'll get out of your numbers.
Right.
Like, why would we do that to ourselves?
So if you look at that whole thing, then a question that I've been asking, and I don't know that I have, I'm starting to see ideas floating around.
I don't have any great answers yet, is how we can present the diff when a human needs to review it in a way that is useful to the human.
Right.
Like, what is the structural intent oriented diff?
And then within that, the machines have said, okay, if that's the intent, then this does what it should.
Or if that's the intent, this part looks a little bit sus.
And this is a kind of thing that looks like someone should review it from a security perspective.
So these 20 or 30 lines are worth looking at, right?
But we open that up and we go, oh my gosh, you know, GitHub's like, diff isn't rendered because it's too big.
That's basically what the page says, right?
That's what it says on all of our PRs right now.
I'm like, well, how is that even useful to me?
But what I really want is, hey, Rob, machines covered 95% of this.
This little to have a look here and have a look here kind of thing.
I just thought of this.
When someone hands me a legal document and I know they've done a good job and there's just like tape flags that say sign here, sign here, sign here kind of thing, right?
Like, great.
I have people that are way better at reviewing legal documents than me.
I just happen to sometimes be the person that needs to sign it, right?
And then there's actually this very similar human context that's like, who was the person that reviewed it and how much do I trust them?
And would I sign a thing based on what they tell me about the thing, right?
Or I'm going to sit here and read every line of it.
And so I think not just the surface when it can be in a lot of cases just automatically moved on, right?
So why are we doing all this interaction with agents talking to each other over some format?
But also then when I do need a human, I think I'm going to surface that.
Different use of surface.
But anyway, I'm going to raise that up to them and flag it in a much more concise way.
Right.
That's like, here's the intent of the whole thing.
This part's a little bit suspect.
So let's just take a look at that part.
Everything else is good to go.
Right.
It's like reevaluating who the process is for.
Obviously, there's still a level of accountability.
has to happen in most cases.
A human still needs the answer for something.
Someone needs to sign off on something.
You're right.
Maybe this moves towards just the DocuSign experience of PRs where it just moves you through the lines it wants you to sign off on or put your eyes on and you're trusting some other system underneath.
Who knows?
But we have to acknowledge at least that the new user experience and then also now the...
the brand new agent experience that they need to be effective at it are very different.
And in that like diff driven world, it made sense to show all of the files and like your folder hierarchy or in a semantic way that like we could glimpse and like know where other things lie.
But now that's noise for an agent who's like counting every single token going into it and trying to preciously contain it.
So it's like what you're optimizing for in presenting information is totally different.
That's actually been really exciting for me just as a developer is, Finding this new class of developer tooling, things in my CLI, and otherwise part of my local coding process that aren't really for me.
The outputs of them, however they're utilized, are really for an agent to audit something or to get a check on something that otherwise has a hard time getting a grip on.
And just using those deterministically with an agent kind of lets them...
It's like its own kind of guardrail, right?
And now suddenly you're bringing things that used to maybe be, maybe this would be surfaced as one of those stamps that's going on the PR.
Now it's happening even closer to the developer, even more locally, even more commonly before it hits the PR surface.
So how do you think about the CICD getting pulled down almost into the developer machines because the development loop is now happening in my cloud platform or with my 30 subagents, you know?
Right, right.
Exactly.
I think there's a lot shifting more left, you know, like as the even within the agent loop before it's asking for human intervention.
Right.
So we're looking at a couple of different things there.
One, we launched something called Chunk Sidecars, which is basically like a direct attached CI quality validation environment that your agent is using as it works.
to say, okay, I made this change.
Is that good?
If not, I'll make some adjustments before I even tell the user, the developer, okay, this change is ready to go, right?
So we think of that as like, again, I call it CI-like, meaning it looks and, well, I don't know if it even looks and feels.
The quality of the validation, right, is going to be much like what you're getting in your CI environments to break away from this, you know, works on my machine kind of problem.
happening in super short cycles, like we're thinking 30 to 60 seconds as a general target and giving that feedback directly to the agent as it's working so that by the time it goes up to like the more classic gate, right, of CI, meaning is this thing good to merge in and go to production, I have really high confidence.
And the other thing that I think about a lot in there is then, you know, who's...
who's writing the tests, right?
Like the agent is going to write the test too.
Let's all be honest about that.
No one's saying, oh yeah, let me just, let me just, I mean, I do kind of, in some types of development, I'll do sort of a TDD style where I say, what could possibly go wrong here, Claude or Codex or whatever, and, and get an answer and say, cool, can you write some tests that would expose that if it broke?
Great.
Now implement the thing, you know, and I kind of go through that, that process.
And that's often when I'm Sort of working through an idea versus have like a really clear plan of what's, but I will still in all of that, I'm using the agent to write the test, which sounds amazing, but the agent loves, I'll just generalize agents here.
They love to like, well, yeah.
Or to stub everything out, right.
To mock everything.
So you're not actually testing any of the business logic or any of the interaction with other systems or whatever.
And it's like, cool.
Everything passes.
Cause its goal is to get to green, not to get to like very clear.
you know, validation that all of your intent is correct and correctly implemented, right?
And so I think there's a role, and we've been dabbling in this a little bit, in, oh, I'm trying to find the right words, but ensuring that your validation techniques are of high quality themselves, right?
That if something broke within your software, if you made a mistake, it would actually get caught.
And there's actually, what's really interesting right now is, We're still, I feel like all cool things in software happen in like the 60s and 70s.
And we're still pulling out techniques that people thought of back then and saying, wow, now we have the data and the compute power and everything else to actually use this.
Like somebody wrote it on a napkin in the 70s.
I was particularly, I'm thinking of something called mutation testing.
And they said, this would be really cool that everyone was like, yeah, where would we find the computers to do that?
Right.
And now you could do that on a phone.
You know, like the compute power that we have to drive this stuff is immense.
In particular, to have an LLM analyze your code and say, oh, these are the trouble spots.
This is where the risk is, right?
And I think risk analysis is a big thing.
When we talk about pulling out the kind of that DocuSign model, like pulling out, look at this and look at this and look at this, right?
So our ability to assess risk and then to assess the quality of our risk assessment, right, is all...
getting back to like what are we doing as engineers right that's where we're putting our energy as opposed to like i sit here and i build a product right because that's scalable right we've been doing continuous improvement as an industry for years but now we're scaling that by saying let's improve the machines that build the software right and if we actually work that the same way we've worked historically like incidents or any retros or whatever then maybe the first time we just say, have at it, machine, it's not going to be great.
But if we dial the tooling on every time we have to step in, that's kind of my other thing about the DocuSign model.
Every time I sign for something, I want to say, why was that exposed?
Why was it possible to create this kind of risk?
And how do we make the machines better so we do this correctly and I don't have to worry about it next time, right?
But if we don't start on that journey, we won't get to the end of it.
I think what's really interesting is whoever you are, whatever company you work for.
You have a competitor that's doing this right now that's doing it probably better than you.
Right.
And so that's, that's like where a lot, and we've talked about kind of the pressure to keep going and to do more and to build more.
Right.
It's like somebody, everybody's kind of checking over their shoulder because someone is, has just been enabled to really like take on, take on their business.
And there's so much like.
unexplored territory.
We all know it.
Like the fog of war is the whole dang map.
And so everyone is very nervously exploring and trying not to get stuck in quarters, trying not to go down the wrong way and waste a bunch of opportunities or time while someone else went and found gold immediately.
Why couldn't that have been us?
And so it's like that's the world that I think a lot of engineering leaders are trying to navigate in.
I love the shape of what you described, how those tools evolve, like this.
CICD-like or something.
The word I've been using myself is almost like a new class of linters.
It's not like smelling my code for formatting stuff as much as it is working with the agent on these really small, tight loops on an incremental editing code or reading code basis to kind of help keep it in guardrails.
It's kind of like linting what it's able to do.
And those kinds of things are allowing us to close a loop.
that up until now was totally open.
We would do the best we could as engineers to create this like ornate pipeline that has like all of the stuff that goes through and checks all of this human effort that goes through this unbounded system.
And since it wasn't really a fully closed loop because AI didn't exist yet, it was kind of more like an instrument.
Like you held it, you played it.
It was like a single player kind of deal.
But now it's exactly what's happened is what you've called out is that like the loop is closed.
So now you can run it.
Hey, Mr.
Machine, do your thing.
And even if it's not perfect the first time, now we can iterate because we spend all of that time building this instrument and playing this instrument.
And while we're not maybe the ones playing the notes anymore, we know how it was all laid out and why we made the decisions we made to get there.
And now we're in a world where it can make itself better, where it can find new purposes, new usage and new tools.
And that's just going to require a lot of experimenting and a lot of measuring.
too, to understand what works for an org because all of that's exciting and like cool to talk about on like an individual practitioner level.
You get lots of folks who've unlocked like 10x or 100x outputs as engineers and are super agentic and they're kind of leading the charge within their engineering orgs.
But on an aggregate level, I'd say as an industry, most orgs, especially the larger they are, tend to be more on the less mature side of understanding AI's impact on their organization.
You know, oh, we know we have Cloud Code.
We know we have Cursor.
We know we love Codex and our...
engineers are using a lot of tokens.
And you've even seen this narrative recently about like people trying to track how many tokens they're burning.
Are they maximizing it?
Or now are they minimizing it?
Like everyone has a different opinion about this now, but I feel like people still miss the whole thesis of like, what did the code do after it was made?
Did it even get merged?
Did it cause an outage?
Did it get reworked later on?
Did it?
exists for a nice long time, did it completely add completely brand new code instead of opting to maybe refactor something that would have made more sense?
Like those are missed signals, I think, for most organizations.
Curious how you think about leading your engineering work right now and how y'all stay tuned on like the output signals that matter.
It's super relevant that, I mean, everything you're saying, the cost is real, right?
The time span from, hey, we got to motivate everyone to use these tools because there's real opportunity here to like, oh, hold up.
What is everyone doing?
You know, was a week, I think, in many organizations, you know.
And there's definitely a spectrum, right, of what you can achieve and what that's going to cost.
And the costs, you know, if you look at it in just raw cost, right?
So ignore at your peril, but ignore for a second budgets, right?
And actual how much cash you have on hand as a company.
So if you ignore that for a second and you just did the math and said, you know, for what feels like an exorbitant spend, I can, you know, 3X the output even or the outcomes.
Let's pretend outcomes for a second.
I can 3X the outcomes of an engineer for a 50% increase in costs.
Like most people would do that all day, every day, right?
It costs real money.
Like someone has to write the check.
I mean, there's not an actual check anymore.
It's 2026.
But money is coming out of bank accounts and going to other bank accounts when this occurs.
And Uber kind of famously, and there's been other examples since, came out in March and said, we spent our whole token budget for the year.
And people care.
Investors care.
Business leaders care about.
total cash spend.
That's a real thing.
It matters, right?
And so then the question becomes, what is the right amount and how do we navigate that as we grow?
And if I tripled the outcomes of an individual engineer, let's try to make the math as simple as possible.
If I tripled the outcomes and I only spent 15% more, like 50% of their salary on tokens or whatever, that would be great if the minute they merged, I started realizing the revenue increase, right?
But that's not what happens in software.
Like sadly, it's not what happens in software.
And so there's still a time delay.
And in that time delay, I've spent the money and I haven't earned back the money, right?
And that would also be if we were perfect at building things that always returned in terms of revenue.
It's more like a portfolio.
We get more for some things, less for other things.
So all that to say, there's a lot of scary math that is...
is difficult to navigate right now.
And predictability is often as valuable, if not more valuable in finance than the actual magnitude.
If I can forecast it, I can manage around it.
If it just comes out of the blue because one day some developer realized how to write a for loop and spun up 100 parallel agents that were just working nonstop, 24-7, none of it was producing anything.
That's great, but...
The money's gone before I even notice it's happening, right?
And so there's a lot of, you know, a lot of people are building controls.
A lot of people are trying to figure out how to put caps in place.
They're doing things like routing, you know, okay, now can I route this lower, you know, trying to educate people on how, oh, you don't need opus for everything or, you know, those sorts of, like, it's happening all over the industry.
And I would say for us, At CircleCI, just as our engineering team, we're exploring a lot of things, but we're trying not to throw too much at our people.
Like one thing we've realized is some people just want to get some stuff done, right?
Not for everyone, every day cannot be, try this new tool, try this new tool.
Now we've changed the way that we're going to do this.
We've changed the way that we're going to do this.
It's like, great, by the time I get updated on today's stack, it's time to go home and then tomorrow I'll learn tomorrow's stack.
Right?
Like we need people to build stuff.
You know, we kind of keep an eye on the outliers, right?
Hey, we see that you've sort of picked up some pace here.
That's awesome.
Can you tell me a little bit about what you're doing?
Because it seems like there's much higher spend than outcome or output even.
Let's worry about outputs.
Probably actually easier.
I'll revert my previous statement because we don't have to worry about like whether we're building the right things.
Let's just talk about building stuff, right?
And sort of, hey, just show me a little bit of what you're doing.
Like, could I tune a little bit about how you think about using the tools?
Can we just click on that thing there that says Opus and set that to Sonnet and see if we get the same results?
You know, like just really basic tweaks because we want to encourage people to build and learn and drive.
And as we, well, I'll get to that one second.
So without a lot of like, either I need everyone to be super educated and detailed and understand, like what's the point of a layer of abstraction if I need you to understand everything inside of it?
And without forcing, again, like new tools down everyone's throat every day, right?
Now I need you to switch to this.
Now I need you to switch to this.
So we're trying to be like a little reasoned about it and pick the points that are going to be high leverage and sort of take advantage of them.
And then the other thing that we're spending time on is as we discover tools and techniques or whatever, can we make those available to everyone in ways that they don't even really have to think about, right?
So, I mean, generally.
Something as simple as a skill will get you to an outcome faster and burn less tokens or fewer tokens because the agent isn't figuring it out for itself over and over.
Right.
So can we take those and distribute them well across the organization, make this part of how people work?
Like, I don't need you to understand the skill as long as the skills are readily available in your agent.
And the first thing, you know, the likely thing to happen is that when you ask an agent to do something, it's going to follow that skill.
Right.
And so there's a lot of that.
kind of work, but I guess to, you know, to summarize, it would be like, I don't want to put the onus on every individual because one, humans are fallible, right?
We know that we're going to forget to do stuff.
We're going to mistype stuff.
That's fine.
It should, that should be fine.
Right.
And I also don't want to create a huge amount of churn.
So I look for like, where are the kind of high leverage points as well as the outliers?
What can I learn from the outliers?
And then how can I take that and bake that into kind of the things that they just end up with for free?
This episode is brought to you by Linear B, the engineering productivity platform.
There's a widening gap between engineering teams that have turned AI adoption into delivered work and the teams that haven't.
It's real, it's measurable, and it's growing every quarter.
On July 30th, Linear B's CTO, Yishai Beery, with Ben Lloyd Pearson and Andrew Ziegler, walk through new engineering benchmarks built on 2.7 million pull requests from 250 plus engineering organizations.
You'll see why high AI usage correlates with a 2x increase to PR merge rate and why more AI code doesn't automatically mean more shipped code.
We'll also cover the lowest effort win that's available right now, turning on AI code reviews.
Register to join live and get first access to the full report.
Save your seat at LinearB.io.
Yeah, it's really important that you create some sort of ecosystem or like substrate for your engineers and just your whole organization, really, because everyone's benefiting from this event is to share.
what's working.
Like we've, that's a practice that's really stood out among all of the, I would say like the top engineering org leaders that we've had on the show about like what differentiated their org's like speed and what it was able to accomplish with, with its own product, like not making something that new, like working in brownfield stuff and doing really messy operations and migrations.
And it always, always, always came down to.
you know, shared skills, shared ecosystem of agents, somebody in this problem over in this org solves this particular problem.
And now there's a way to distribute it to everybody.
So we're not all constantly reinventing, relearning the same stuff in a silo, which is crazy expensive for what we're trying to do right now.
And exactly to your point, like your job as an engineering manager becomes even more.
abstract because we talked earlier in this conversation about how like oh now the engineers were managers and we're we're managing we're influencing this environment to have this outcome that we want.
Now you are influencing the people who are influencing these little micro environments that are influencing the outcome that then you are paying for.
So it's like this huge, even bigger loop.
And so you have to have these practices of like understanding what models folks are using, having picking the right model for the task.
Like we've talked a lot on the show, especially recently.
As you know, like all so many open source models have hit the scene recently that are just like really top notch and are really working for orgs and bringing their bills down really low and unlocking just like new architecture because now suddenly they can run something through 10 agents at a third of the cost or something.
So you're seeing a lot of cool innovation with these types of models.
But along the way, it's like we have to learn.
when to choose the right model for the task.
And I think that has a bigger payoff from a lot of engineering orgs than maybe they give it credit for.
It's if you really helped educate and onboard folks about when you reach for Opus or when you reach for a sonnet, or even if like, you know, you're going to sum it up with a haiku, know when to pull that one out.
So like understanding the impact, I think on the show recently, I said, back when we had Fable, you know, for like five seconds, I said like, don't use Fable to check your mail.
Like you're riding a dragon.
Like you don't take your dragon to go to get your mail, right?
And I think that's the reality of like so many engineering orgs in the last year is it's kind of like all the execs just like...
rolled up to the office with all these like Ferraris and then just like threw the keys to like all the developers like go have fun and they're out in the parking lot they're doing wheel they're doing like you know cartwheels or whatever like the wheels are spinning around the whole there's smoke everywhere yeah they're using all of the gas yeah they're putting lots of miles on the machine yeah they're like fully understanding how to drift it and turn it out and do whatever but then when you're done and all the smoke clears you know what do you have Like they didn't build anything.
They didn't even go to a racetrack and like win a race against somebody else.
They just are doing wheelies in like the parking lot of your office.
And that's what a lot of engineering orgs have been doing with understanding, getting like a control on their AI spend and tying it to like the outputs and understanding that it's a system that you have to influence.
So it's like been the biggest challenge, I think, for folks.
I think that's exactly right.
And there's a couple.
pieces of there that really about the learning, right?
Like, absolutely, you do need to take some time, like you're not going to win a race.
If you didn't at least take the car out to the parking lot and go around a few cones or whatever, right?
Like, not to downplay racing, I think it takes a lot more than that.
But so, you know, you need a little bit of space, I think, for ICs to learn.
And you need some space.
As leaders, it's easier to make space.
You need some space, in my personal opinion, some investment from leaders to learn.
Because to have useful, credible, productive conversations with your team about how we're going to use these tools effectively and what that might mean for us, as a leader, you need to understand.
to understand it right like i could just say please choose the right model and then someone's going to say to me well when should i choose and i'm like i don't know i've never used any of this stuff like figure it out you're an engineer you know it's not a really helpful conversation and you know then someone says to you well it only ever works if i use this model right and you're like oh i don't know i heard on the internet that it's possible to do other stuff like it you know there was such a a loss of experience for most engineering leaders in a very short window of time but like much like every ic to varying degrees and different outcomes went through a, what am I in this?
What expertise do I have?
What do I bring to the table is what I've learned and done in the past interesting and valuable?
The answer is yes, but how do I take it and apply it to this scenario?
Leaders go through the same thing, right?
Because as leaders, a lot of our credibility, a lot of our ability to solve problems or to guide people through problems comes from our years of experience.
How software systems are put together, still valuable, but how I sit and build something day to day, totally different now, right?
So for me, a big part of this has been...
investing time and energy and using all the different tools.
And I just like, I typed something into cloud code once, but you know, I've used cloud code and cursor and codex and pi.
And I've tried some open weight models and personally had terrible results, but it taught me something about what else I would want from them, right?
Like I tried to go to the cheapest possible thing just to see what would happen.
And it was, it was abysmal.
And I was like, cool, that's interesting.
But I see how they're progressing.
And could I build a system that I could put that really basic model into?
that would then produce a result, right?
Like to your point, if I could do more passes, right, can I tune that in a way that gets the same result as just going and getting the dragon model, right?
But I'm using my salamander.
I'm not really sure what scale we operate on when the top end is a dragon.
Yeah, exactly.
Like I'm going to use that and it's going to give me a little bit, like a little increment and I can, you know, work my way there or whatever.
But to even have...
For me, I know people think differently and I have my own biases or whatever, but to even reason about that intelligently and to be able to ask good questions of my people and sort of push them to try new things, it's been a big investment for me in just developing my own understanding.
Yeah.
And then, I mean, I think this is, for those of us in developer tools, an added bonus or maybe an added driver.
Like I have to understand what my customers are going through and able to be able to build the right product for them.
And if I don't understand the tools and I don't understand what my own people are going through, there's no way I'm going to understand what my customer is going through to be able to say, oh, we tried that and here's what we did.
By the way, we added this capability to our product or here it is for free because it's not really interesting as a product depending on what it is.
And so, you know, it's been a real journey for me, for leaders in my organization to.
you know, to try to understand where all this is going.
And again, where it's going today, tomorrow might be slightly different, but I feel like we're getting a handle on it in a way that we at least have some strong opinions about what to do.
Yeah, we're in this like messy middle now, for sure.
In terms of like, there's a lot of stuff that we know we don't know and that we have plenty of time to optimize on.
the jagged frontier of they could stop innovating on all things AI and dropping new models today and there'd still be years upon years upon years, decades even of work to be done just in terms of figuring out what do we do with all the stuff in our hands.
But that's not how the pace is going.
We're going to get even more stuff.
It's going to go even faster.
There's going to be turns up ahead that we don't see yet, which also speaks to kind of the environment that engineering leaders are in in general.
They have to be nimble.
We're not an environment.
You can start like building that castle like brick by brick because everyone knows very much so that like you probably are going to have to pick up each of those bricks and carry them somewhere else.
Maybe in the next 12 months even, you know?
Yeah, I think that's, it's so true.
It's probably, we talked about curiosity, right?
As a trait.
And it's absolutely a good trait to have at the moment.
I identify as entrepreneurial.
You know, to say, oh, I've been at the same company for 12 years doesn't sound entrepreneurial, but like I've, I did many things, but all of my career has been starting companies and, you know, getting acquired in companies.
There's a hundred things all at once.
Yeah, exactly.
And, and so it's a good time to have that mindset, I think, right?
Like if, if you've built a company and gone through multiple pivots, not this one, but the, you know, the thing that, that our CEO and I did, but ended up at that.
got us into CircleCI.
Like if that's how you think and that's how you reason about, you know, then the next pivot doesn't feel significant.
And I'm not saying like tomorrow CircleCI is going to be selling teddy bears online or something, but things shift so much.
And whether it's internal, like how our approach and how we want people to work and whatever, you know, there's a lot of questions out there about how traditional roles start to break down.
Like what is the makeup of a product team?
Do we have this kind of delineation of designer and PM and EM and tech lead and whatever?
Or do things get a little smaller and people just form groups that happen to have those attributes?
And if you're comfortable with reinvention in a way that I think in an entrepreneurial world, you're just comfortable with a lot of stuff, then that comes naturally.
If you, much like the IC who believes what they do is write lines of code, If you're a leader who has built their whole career on building large organizations structured in a particular way, and that's kind of your playbook and you rely on that playbook, like someone just pointed a blowtorch at your playbook.
Maybe it was the dragon, actually.
Maybe the dragon burnt your playbook, but it doesn't exist anymore, right?
And if you're clinging to that, then you're going to have problems.
So I do think it's good to be comfortable.
acknowledging my own biases.
Also, it's important to know that you're probably as a leader more comfortable than other people are.
So there's a lot of change management in this happening at a pace that change, like that change management can't happen.
And that's really tough for organizations, right?
It's like, I know we just started talking about that thing from yesterday, but also today there's a new change and trying to help people through that has been, you know, is I think a big part of the job for a lot of folks right now.
Yeah.
And I think in this conversation, you've really shown a lot of light into...
the messy reality of being an engineering leader right now and being in charge of software coming into being as like your direct influence on the code and the ultimate product get further and further away.
I mean, we're moving into a world where like the code isn't even really necessarily where the truth is or where the interesting stuff is.
A lot of that stuff now happens in the transcripts before the code or in the observability once it's been deployed or it's living in the wild.
But.
In no world in that pathway do I think something like CICD would go away.
If anything, I think CICD would just level up into this really amazing harness that sits on top of the whole engineering process that also exists all the way out into the front gates of where your product goes out to interact with customers, but all the way back into the core of your org and on folks' machines and within their dev loops and available to their agents on demand.
stuff that we call CICD that starts to fall into that world.
And it becomes this big, exciting engineering problem to build towards.
It becomes this impossibly large problem space to solve for.
But if there's anyone up that...
If there's anyone that I know is up for the challenge, it's you and CircleCI.
And so we're excited to follow where things go for you, Rob.
And just as we kind of bring things to a close as well, is there anywhere you want to point folks towards to maybe learn about the latest from your engineering org?
Thoughts top of mind for you, product announcements as well?
Yeah, I mean, obviously our website, circleci.com.
try to put what I'm thinking on LinkedIn.
Sometimes I'm so buried in what I'm building that I forget to write about it, but that's a good spot.
I mean, find me on LinkedIn.
Those would be the two places I would start.
And, oh, we have a newsletter on LinkedIn also that I would recommend.
I mean, it's a place that we put, you know, we do the status software delivery report once a year, but we're thinking about it all the time.
And we've started pulling the numbers more regularly because like, what they looked like a year ago is going to be so irrelevant after a year.
So we're trying to put that out in this newsletter.
And then we pull individual insights from it.
It's called the Confident Commit newsletter, which is also the name of my podcast, The Confident Commit.
So those are some options.
But yeah, we're doing our best.
Sometimes it feels like our thoughts by the time we try to write them down are irrelevant.
You know what I mean?
Oh man, you're speaking my language right now.
Doing this podcast right now is...
I got to move at the speed of light.
Yeah.
It's wild, you know?
And so I actually, I have done my best.
I happen to be in the Bay area, which is super convenient.
I'm going to an event tonight.
In fact, um, And gather.dev.
No one will.
Well, it'll be too late to go to this one by the time you hear this, unless it's published in the next 30 minutes.
But gather.dev, which is like a director plus group here in the Bay and in New York.
People hear it and should check that out.
But yeah, I just try to get out to as many in-person things as I can.
And again, I'm blessed by being in the Bay Area.
This is a lot.
Actually, it's more I'm the limit, not the number of events.
Like at some point, you just can't go to that many.
But right.
Because the real-time conversations are so important, you know, because by the next day, like I take that and I synthesize it into ideas and then we move on and we move on from there, right?
So again, I'm trying to put this stuff out, but I'm also sort of burying myself in these.
And if you're ever at one of these events, obviously you, but anyone that's listening to this, please come say hi.
You know, I love to meet people and just learn about what other people are working on.
I have, I'm good at synthesizing, I think, but I don't have all the ideas, right?
I mean, everyone's coming up with some amazing stuff and, uh, and just trying to see it all and piece it together is, is really fun for me.
It's so fun going out to events right now.
So if you're in San Francisco and you happen to see Rob out in the wild, be sure to approach him, say hello, say that you listened to him when Dev interrupted.
Also be sure to reach out to us on LinkedIn.
Both Rob and I love getting comments or questions or feedback from folks, whether you like or didn't like what we talked about today.
It's always good to be out there and interacting with folks.
And so definitely come find us and share your opinions.
And for everything that Rob mentioned as well, we'll include links into our show notes.
And to you, our listener, thanks for joining us on Dev Interrupted by Linear B.
It's been a blast and we'll see you next time.
Awesome.
Thank you.