Rob Zuber: Every software engineer is trying to figure out how their job works, and we're trying to solve problems for those software engineers. As a leader, it's much more difficult to lean on all of my context and experience. I have to build fresh new context and experience, one step ahead or a few steps behind the people on my team, trying to be there with them, figuring this out.

Rebecca Murphey: I'm Rebecca Murphey, and this is Engineering Unblocked. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform trusted by some of the best software companies in the world, including startups like Superhuman, scale-ups like Miro, and companies from the Fortune 500.

On today's show, I'm talking to Rob Zuber, CTO at CircleCI. Rob, welcome.

Rob: Hi.

Rebecca: You are the CTO at CircleCI and have been for some time, which is not always typical in the industry. We're recording this at the end of 2025. What does it mean to be a CTO?

Rob: In 2025? Oh my goodness. Well, as you said, it's been a while. I could tell you the answer for many years — over a decade, in fact. Being a CTO in 2025 is not specific to CircleCI but rather a challenge everywhere. So many things are changing so quickly in terms of our perspective of what product can be, what we're building, how we're building technology, in a way that has forced a lot of folks — I can speak for myself, but I also talk to lots of people — to be more involved technically.

Particularly in developer tools, for a long time I was able to live off of my understanding of how developers worked. Having been a software engineer, I knew what everyone was trying to do. Let's go build it. Here's some ideas. I'll get out of your way. Now it's much more exploratory.

Every software engineer is trying to figure out how their job works, and we're trying to solve problems for those software engineers. As a leader, it's much more difficult to lean on all of my context and experience. I have to build fresh new context and experience, one step ahead or a few steps behind the people on my team, trying to be there with them, figuring this out.

One big thing in 2025 — and I think this is true for a lot of folks I've spoken to — is just a lot more involvement in the day-to-day process because it's so much more exploratory, and a lot less "we made a plan at the beginning of the year and we just execute on that plan."

Rebecca: That resonates a ton because we also build dev tools at Swarmia, and same theme — we have a bunch of super experienced software engineers who, you know, the experience they have is valuable, not discounting it, but it's not enough anymore because the landscape is changing so quickly.

CircleCI goes back a long time. If I did my homework right, CircleCI emerged during the rise of cloud DevOps in 2011, and you joined a couple of years later in 2014. Setting aside AI for a minute — we'll get to that later — what are the big changes you've seen in software development since starting in 2014?

Rob: I'll go back to 2011 because CircleCI was of a moment. It was Rails monoliths being deployed to Heroku. Every startup was cookie cutter — not the same business but the same approach. The stacks were all quite similar. There was a lot of trust being developed in cloud. People wanted to deploy to Heroku. The Rails community was very "you must test" — rails scaffold would give you your test suite. That forced a perspective that CI was good, that testing was good, that delivering quickly was good.

But there wasn't necessarily a bunch of infrastructure experience. Saying "hey, we'll do that on your behalf" was the promise of CircleCI at the time. The company had product-market fit the afternoon of launch. Everyone was like, "absolutely, we need that. We're going to do that right away. Thank goodness, because we didn't want to have to build this out ourselves."

I joined in 2014. In 2011 I was actually building a Rails app deployed to Heroku. We went through some pivots and started building mobile apps, and ended up deciding the tooling was terrible. We built a mobile CI/CD platform and basically joined CircleCI in 2014 with that offering.

That's a really good indicator of what was happening in 2014 — from everything was web first in 2011, and by 2014 everyone was building mobile apps. The iOS App Store had been around longer, Android had been around, but that was when it became the default. You started with mobile.

One thing I always mention about that time: if you look at the early tooling around building iOS apps, the testing frameworks, the package managers — all of it's written in Ruby because all those developers came to iOS. They came from building websites and showed up saying, "what are you people doing? There's no testing, there's no package management."

Rebecca: Sounds like JavaScript, to be honest.

Rob: Right. When everyone is developing in an ecosystem, it gets a lot more attention and people bring experiences from elsewhere. One of the things I love about learning multiple different languages and working in different ecosystems is people bring experiences. iOS tended to be a little more insular. Then this whole crew shows up from Ruby and goes, "oh my goodness, this is unacceptable." They could probably build a package manager or a testing framework in Ruby way faster than in Objective-C because they're still learning that language. So there's this weird historical piece in there. 2014 became very mobile services.

Rebecca: I remember working at that time on PhoneGap, where you would write basically a web app and put it in a wrapper. But Swift didn't exist then, right?

Rob: I remember going to some developer conference where they were just starting to talk about it, an Apple developer conference. I think I was already at CircleCI. So it's around that era, but it was a long time before it really became the dominant approach. People already had a language they were comfortable with. There was a long period where Swift apps were very bloated compared to Objective-C apps because there were some extra translation layers. It took a long time to really get a large foothold in the community.

As I was building what we were building prior to CircleCI — building apps and building tooling for apps — I was writing a lot of Python. I wasn't writing Objective-C anymore, but all of our customers were still building in Objective-C at that time.

Rebecca: I remember something called Objective-J, which was in the late 2000s—2009 or something — which was "we're going to write JavaScript in Objective-C." With the hindsight of history, obviously that was a terrible idea because even Apple didn't want Objective-C. So the idea that we were to write more of it and make it transpile for JavaScript — I mean, I tried it because that's what you do when there's new JavaScript frameworks.

On the theme of transitions over that time, it would be fair to say there's been a new JavaScript framework every six months.

Rob: Hey, but that's calmed down now.

Rebecca: Yes.

Rob: I think there are bigger players now, bigger support. When you think about React with entire companies behind them, Next... I'm not really a front end or JavaScript person for the most part, but I see that slowdown.

For me, as someone who doesn't spend a lot of time in there, React was a fundamental change in how to think about the front end that was really useful. We're no longer just searching around for whatever state we might have left something in and hoping we can find it, but actually deciding what we want something to look like.

The other big transition before we got to this era was containers. Docker. We had a containerized platform built on LXC because Docker didn't exist when CircleCI started. That was really novel, what we were doing. Then suddenly everyone was containerizing because it was a model to get to clear deployment.

But then they got convinced that because they could put things in Docker containers, they should build hundreds of different services. They needed to coordinate those. Then you had the orchestration wars. I think 2016, there were ten orchestrators, and 2017 there was one. It was really that fast. Kubernetes — I mean, Google put the weight behind it. By 2017, I think every orchestrator was just a wrapper on Kubernetes.

That was probably the last — I must be missing something — but that's the really big shift because we felt that as a company. How we provided service to a Rails monolith versus how we provided service and capabilities to people building hundreds of microservices and building them inside of Docker containers was just very different.

Our goal was the same, but the approach we had to take... we re-architected our whole platform to make that work effectively. Part of that was scaling at the same time and reaching limits of our initial architecture. But there was a huge amount... I could talk about this all day because the product that we have to build is so influenced by how software developers work that we really felt all those changes.

I'm a big proponent of boring technology. I have all the battle scars to convince me that that's the right way to approach it. But at the same time, as a business, we have to be very far ahead of the curve and even be trying things, not just reading about them, to really understand how developers are using them so that we can build the right product.

We sit on this knife edge between trying to build things that are super reliable and stable — let's use the thing that we've battle tested a thousand times — and we have to try all the nutty things that every developer is doing.

Rebecca: That your customers are actually doing, right.

Rob: Right, yeah.

Rebecca: CircleCI was a pretty early entrant in this space with instant product-market fit. It's been 11, soon to be 12 years. At that time, people were hungry. This was obviously a missing piece of software development. Getting customers was, I imagine, quite easy. But now there are lots of competitors. How are you keeping relevant and competitive in a world where there are lots of other services that offer something similar?

Rob: I would say two things. One, I'll go pre-2025, and then what we think about in 2025.

We actually launched into a world of competitors. We have slides that we've made in the past that show all the different CI/CD companies coming in and out of this space. AWS has been our competitor three times with three totally different offerings. We've seen cruise control from the late 90s, 2000... there were a ton and they've come and gone in our time.

I'm great friends now with one of the founders of Travis CI — that was our cohort. It was CircleCI and Travis at the same time, but very different approaches building very similar things. They were approaching this from an open source perspective. We were going after the commercial offering.

What's interesting is the products probably look and feel very similar, but when you're really in it, you can see distinct approaches to different capabilities that we would focus on and they would focus on. I think that's one key element. We've always been in a pool of a lot of competitors, and knowing who you are and what you're shooting for and which customer you're going after and what pain they feel every day when they wake up is what has allowed us to stay relevant and competitive and differentiated.

Simon Sinek is really good at describing this kind of thing — really understanding what you're solving and who you're solving for, why you're solving it. When you have a connection with that group, then you're always going to be in with that group.

We think of our group as the people who really care about software delivery. I get up every day and want to be great at this. There's a lot of "good enough." Before I joined CircleCI, before we started building a CI platform, we were building on Jenkins. Jenkins changed the world in terms of people being able to do this, but I don't get a ton of love anymore from people who are using it. They're like, "I don't know, we don't know how to get off of it. We're kind of stuck with it." But the world has moved on.

We wake up every morning and just think about the customer that we care about, the person that's trying to be really amazing at software delivery.

Now, all that said, everything is changing right now. I don't even know if CI is the thing in another year. People want to deliver high quality software. They want to move really quickly. You're very into developer experience and productivity. That's what really matters. We've recently accelerated one of the steps — we can generate code faster — but we haven't figured out all the rest of the pieces.

What matters most to me now is not what are any of my competitors doing, but what is happening in the space? How is software delivery going to evolve? What would amazing software delivery look like? Even though not all my customers can see it, how can we create that opportunity for them and that experience? Then we have all the room in the world to be relevant.

The whole slate has kind of been tossed up in the air, and that's exciting for me. I'm an entrepreneur by background and history. I think there's a huge amount of opportunity. What's most important to us now is not what is one other person doing in CI, it's how is the whole software delivery lifecycle changing and how can we make that amazing for people?

We have always been concerned with people delivering high quality software to their customers quickly. Speed wins in the marketplace. The faster you move, the more likely you are to differentiate from your competitors. The way that you do that now is changing so fundamentally that I don't even know who our competitors are, if I'm totally honest. I know lots of people that build stuff like we build, but I don't know who's headed where we're headed.

Rebecca: Tell me when you find out. Same kind of uncertainty in any dev tooling, I imagine, is going through this right now.

Rob: But it's exciting. I mean, speaking of the tenure — when we first joined CircleCI with two other folks because we were building this mobile platform, one of my colleagues from that is the CEO of CircleCI and has been for basically the whole time. When we joined, fundraising was like, "no one's going to spend money on developer tools."

Look at where we are now. I at least feel verified or validated as a result of that experience. It's delightful to be part of such a rapidly moving, rapidly growing ecosystem.

Rebecca: In the context of this customer focus, customer obsession, that you have as part of your DNA, how does that translate into very boring things like setting goals and choosing priorities and who's involved in that and how do you manage conflicts in those?

Rob: That's probably... yeah. I mean, again, we had a very long stretch of "a little bit more, a little bit bigger" — this year is the same as last year but we'll have more customers and bigger customers. We were almost — not entirely, I mean, we were expanding and adding capabilities — but a lot of that was driven by a natural shift in the market as organizations realized, "hey, there might be something to this continuous delivery. Maybe we could be better at software development."

We could have a much more calm goal-setting planning cycle. Now we're really back to more of, not everywhere, but certainly in the parts where we're trying to invest in the shifting market, more of a zero-to-one. This is about discovery, about putting things in front of customers and seeing how they react and whether that helps them.

That is a good stress on an organization in the sense that it forces you to be better at certain things. If it's really clearly linear and your projections are pretty straightforward, that can mask lack of understanding or decision-making drifting upwards because decisions don't have to get made that often.

But to really be responsive requires a much better understanding of goals and objectives down at a team level. I think the thing — I haven't really gotten into the people, but assume that all the normal cast of characters are involved. We have designers and product people and engineers.

A lot of time now I spend trying to convey a picture, a fuzzy but some picture of where we think the future might be — where the future is 14 days from now — and how we would be well positioned to end up there, so that teams can make better decisions at a localized level.

I mentioned earlier being back in the tech and just trying to understand how things work. A lot of that is me, just the way my brain works, puzzling with the things and saying, "okay, if this works like this and this works like this, what's missing to make this great? And how could we play a role in that?"

Then, "hey everybody, here's the—if this were the thing, what would we go about doing? What role could your team play in this and what role could you play in this?" I need folks to have a better understanding of that because the market is shifting faster.

If the market is taking bigger turns and you are going in a straight line for too long, the miss is much bigger. That's the biggest change right now — being in this market. I imagine this is true for any organization, but certainly developer tools where we're watching the whole thing just be turned on its head. Not just paying close attention, but paying enough attention to make bets about how things might play out.

This wasn't really in your question, but I've been thinking about this a lot. From a technical perspective, it's always been true that architecture decisions tend to happen on a longer time frame or be impactful on a longer time frame than product decisions. The architecture decisions are still on the same kind of time frame, but the product decisions are getting shorter and shorter.

A big part of what I do in this process is try to help people think about the approach, the design, that it's not overly expensive and generalized, but allows for what we think are the set of possibilities that are likely because we're probably wrong about our first attempt. Some news is going to come out on Monday morning and we're like, "oh, well, that part of the market just vanished. Let's go over here."

If you're like, "but I was building the entire architecture to support this page on the website," you're going to be really sad. It's a little bit of pushing down some understanding and then bringing up some understanding of how to design, I guess, for fuzzier futures. I'll call it a skill. That skill goes away or gets diminished as you have a very clear projection of where you're going.

Rebecca: Have you managed to sign an annual contract with any AI provider?

Rob: We have an interesting take that I think might be developer tools oriented as well, in that in a lot of places we like to standardize. This is the basic toolkit that everyone uses. You show up as a developer, you know what you're doing. We like it — doesn't mean we're great at it everywhere and we have all of our standard hiccups in developer productivity.

But when it comes to AI tooling, at least for developers, we want our developers to try all of them. We want them to experience the strengths and weaknesses of everything that's happening in the ecosystem so they can see the gaps.

If I were just running an engineering organization at a bank, I would want my developers to be as productive as possible. We would take out a small team of trusted engineers and pick the tool, and we would go all in on that tool until obviously it flamed out and went out of business. We would try to make it so that everyone had a standard approach.

The standard helps because everyone can help each other — "look, I learned this cool trick." But struggling with the tool is actually the value often for us, because we're so early. Having our engineers say, "I tried this and it's garbage," and we're like, "great, tell me more. What could we do to make it not the case? How could we help developers who are using that tool? What do we think about this tool?" Really building that knowledge and understanding.

We have a little bit of sprawl in a way that's not the way we think about a lot of tooling, but because so much is changing, having all that perspective and having people say, "oh, I tried this and I love it, and this is what I love about it. This is a really cool feature or this is a novel capability" — all of that is really interesting to us.

We have kind of a potpourri of developer tools internally, less so in terms of standard — everyone in the company has access to Claude to ask questions and do some work. But when it comes to developer tools, we're a little bit — it feels chaotic, but it's intentional.

Rebecca: I asked about the annual contract sort of in jest, but I think that approach is where a lot of companies should be right now, especially in the dev tooling space but even beyond the engineering space.

One tool, maybe more, especially once you look outside of engineering, which is why I think we're going to get a lot of, perhaps more leverage out of AI-assisted code generation beyond just code generation. Because as you said, if you have any bottleneck downstream, then you've just made it worse by making there be more code.

Rob: Yeah. I feel like I need a footnote for my customers that are listening. We absolutely do look at the models that we use. I think that's really interesting because initially when everyone was launching into this space, it was like the IDE or the interface and the model were tightly coupled. I'm giving you a plugin to VS Code, or I've got a fork of VS Code, or I wrote an entirely new IDE, which was all a gateway to the model.

I think now people have realized you can decouple those things, and I can go back to using Vim if I want to, and I can talk to whatever model. The interfaces and the models have become a little bit independent in a way that is really interesting to me. We actually use a lot of different tools and then point them at our corporate-approved models.

I think that's really telling in terms of what this market is becoming. Honestly, if you move into agents and all you're doing is controlling multiple agents off doing their own thing, which I love to think about, but I'm not capable of doing — an IDE is a really bizarre interface to try to do that from.

I think we're going to start to see those things separate a little bit and we'll care a lot more about prompts and context and models than we will about... we've always let our developers use whatever IDE they want because they have keystrokes memorized and it's just not worth worrying about.

Rebecca: I think the tooling stuff is interesting because I also talk to a lot of people in the industry who are still on Copilot. That is their engagement with the space, and it's limited to Copilot. They haven't explored things like Claude Code or these things that are much more agentic, much more independent.

I think there's also a risk of vendor lock-in in that regard. Copilot was a great thing to buy in 2023, but maybe not in 2024 and maybe extra not in 2025.

Rob: I don't know. How do I prompt? How do I interact with it? They're all tuned slightly differently. Am I relearning all this tooling every other week because some benchmark says that this model is better? I feel like that hopefully stabilizes a little bit so we can focus on doing the work at some point.

Rebecca: Yeah. What sort of things are the board and your CEO holding you accountable for in this wonderful era that we're in today?

Rob: It's a really interesting question because I can't figure out if anything has changed. At a super high level, what does it mean to be successful as a CTO? One, everyone does the job totally differently, so it's a really weird question to ask about. But on another level, you're an executive. Your first team is comprised of other executives in the organization.

I try to have this conversation with people regularly — I am the leader of technology, but I'm not the person who does the tech things. I am a member of a team who happens to have more depth likely in technology than most of the other people sitting around the table. But I'm trying to solve the company's problems. Some days the company's problems have nothing to do with technology.

Certainly in 2025 — aside from AI, though it's AI-adjacent — you have this whole founder-led marketing or content marketing. I've always been someone who is out with customers trying to understand their problems, trying to help them understand how we think about them, how they can be better, putting out thoughts in the market. Not thought leadership, but just putting out thoughts and trying to engage in the conversation about where this is all going.

I come at that because I have a technology background and our customers are very technical, but I'm not doing that and writing code at the same time. Maybe my agents are writing code on my behalf.

A huge part of what one does as a CTO or as an exec is whatever would be most impactful to the business today. It sounds really easy to say, but everyone, no matter what level you operate at, is guilty of falling back into their comfort zone. If you're very technical, you think technology is the solution to every problem. Which I still do.

How am I measured? I'm measured on the success of the business. What I'm held accountable to is making the best use of the funds that we have to create the largest impact.

At lower levels, and in some cases at executive level, but more at lower levels, people get sucked into turning that into non-monetary terms like headcount and tech debt. I say this all the time — I run this workshop at a couple different conferences. One of the things I always talk about is turning everything into the common denominator of business discussion, which is currency. I'll say dollars because we're both in the US, but euro, pound, doesn't matter — whatever your business operates in. You should be able to turn everything that you do into some dollar impact.

As you get higher up, you're going to have bigger error bars on what you think the impact is going to be. That's okay. It's part of the life of an executive. There's a lot of ambiguity, a lot of guesswork, a lot of going with your gut.

To the point of being in the same job 11 years, you get paid on — or held accountable for — the statistical outcomes. If you make more bad decisions than good decisions, then you're going to have a problem. But if you're generally driving the business up and to the right, and every once in a while you make a bad decision or a decision that works out poorly — because you can make a great decision and still have a terrible outcome, that's the reality of complex decisions and complex environments — over time, you drive good returns on the investment of dollars that you have the opportunity to spend.

We generate money, we generate cash, then we spend cash and we try to spend that cash to generate even more cash. At the end of the day, I understand what tech debt is and how it's impacting my team. I understand what the product opportunities are, but I have to decide or help others decide we're actually not going to do this thing right now that sounds like a great idea, because we can do this other thing and we're going to spend the same amount of money and get a much bigger return on it. So that's what we're going to go do.

If you can't make that conversion, you struggle at an executive level.

Rebecca: Yeah. I feel like — and I'm curious if this has been your experience — one thing that seems very different at the leadership level is this new focus on business outcomes. It always should have been focused on business outcomes, but it feels like there was a period around the time that CircleCI came on the scene until around 2021, 2022, where the job was hire, grow, retain, and money was easy to come by. In my experience, it wasn't always necessarily a focus on the business outcomes. There was focus on how much are we doing and how quickly are we doing it.

Rob: I think that varies organization to organization. I think what's different is not so much business outcomes yes or no, but rather the investment model that you're operating under and the market that you're operating in.

When everyone has unfettered access to capital — let's be totally honest about it — then your competition is investing ahead of return in order to generate maximum growth. Business outcomes in those markets are often measured in revenue growth purely on revenue growth. As an executive, as an organization, you're being held to executing at a pace that is achievable when you have unfettered access to capital, and delivering returns on that in a way that will generate more unfettered access to capital.

Even with hindsight, I wouldn't say that that approach is flawed. I'd say it is time-bound.

The very rapid, abrupt transition from zero interest rate policy to post-ZIRP — whatever era we entered, which actually became a tale of two economies, AI or not — that transition is like the end of a game of musical chairs. Depending on where you are in your growth and how much money you've just dropped in the bank, you could end up in a spectrum of states from "cool, we don't need to hire anymore. We got $200 million in the bank, we'll tighten things up, we'll be a little more productive and we're good to go for another three years" to "we were just about to raise, we're running this thing on fumes, and we have no idea how we're going to make payroll next week."

Somewhere in the middle is probably the right fit. One of the lessons that a lot of founders or whoever was doing capital raise learned was about the value of pricing and fundraising. If you were priced to absolute perfection of the market and then the wheels fell off the market, you see a lot of down rounds, a lot of disappointing numbers, because those weren't realistic.

Public markets move up and down every day and everyone thinks that's normal. In that type of market, there's plenty of opportunity for organizations with zero sense of responsibility or accountability or good use of funds to continue to operate. But they're hard to tell apart from the ones that are just growing really successfully because they're putting the money to work.

How companies ended up at the end of that — a lot of it has to do with just the timing of how investment cycles work. As an individual organization, you're going out 18 months, 24 months to raise again. You could have been three weeks after raise or three weeks from raise, and how you ended up at the end of that was a very different outcome. I haven't really thought about it, but I don't know what you would do differently. That's kind of the way the VC market works.

Rebecca: I just always think it's interesting to compare and contrast. I remember weeks where the weekly management meeting was about how your hiring is going, and that was all we talked about. We didn't talk about what we were getting done. We just talked about did we have enough headcount.

Rob: I think that's a real risk. Given what you do, I know you know this, but there's not a direct linear correlation between the heads that you've added to your spreadsheet — hopefully we're hiring whole people — and the output, let alone the outcome.

There is a reasonable relationship. If you have a larger team, at some point you should be able to make that team more productive. I think many organizations probably wish they had done the work they're being forced to do now before they went into those growth curves.

Everyone talks now — I keep hearing this sentiment that AI is an amplifier. As you try to accelerate, you can tell whether your processes are good or bad because you either accelerate or you fall on your face. The same could be said for hiring. If you have broken processes and poorly understood software that's very complex and no one knows how to work on it, a bunch more people trying to figure out how to make progress — it's not going to help.

But if you're super dialed and you have a very simple system that's easy to understand, it's well partitioned, fast flow of change, to quote the Team Topologies folks, a good organizational structure, then you can add a lot more people successfully and grow more successfully.

We're kind of testing the same thing. I hadn't thought about this until right now. We're kind of testing the same thing and stressing the same things. The difference is there won't be as much...

Rebecca: Yeah.

Rob: Right.

Rebecca: I think that comparison is really apt. It's very interesting because I've been in the developer productivity adjacent space for years now. Seeing companies decide to do the things that they should have been doing all along, or recognizing that the things that were slowing down their humans are also slowing down their AI, and they could have had more human productivity at any point if they had just invested in high-quality fundamentals.

Rob: Right. It works for you.

Rebecca: The less generous version of my question has always been, how is it that we have more empathy for these machines that are struggling than we did for the humans? But just in talking about how these are sort of the same thing, I think the time scale is very different.

Rob: Watching AI struggle is like watching your human team struggle on time-lapse camera. It took ten years for all of that. At that slower speed, you don't quite notice it. But when you try to acutely rocket up the curve, it becomes really obvious. Therefore that applies time pressure.

Speaking as an executive, throwing shade on executives — our attention span is super short. So to see that over a long curve and say, "oh yeah, this is the thing that's really hurting us" is harder than seeing it in weeks.

I also wonder if people get so accustomed to headcount — the cost of the people in their organization — maybe it's just a time scale thing. I hire and I hire and I hire and it sort of ratchets up. But one day I go sign this annual contract with an AI provider and I'm like, "I need to demonstrate ROI on this in three months because we need to be blowing the doors off by the end of the year."

I keep hearing 2026 — or maybe late 2025, let's call 2026 at this point — is sort of the period of reckoning where everyone's saying, "cool, we spent all this money on these tools on promise. Has it worked out? What have we gotten?"

Speaking of being a beneficiary, developer metrics, developer productivity companies are like, "cool, we can help you with that. It's about time you measured what was happening in your organization, and we're here for it."

On the one hand, joking about the empathy, it's a bit unfortunate that we didn't have this insight earlier, but better late than never. We'll build better organizations. We'll hold ourselves accountable, and we'll focus on the things that really matter.

Rebecca: Do you think there's a risk — and again, probably not in the developer tooling space because we've lived and breathed this for a long time — but do you think there's a risk that some companies are just not going to be able to be competitive anymore because they don't have those fundamentals in place?

Rob: Yeah. Short answer, yes. I believe we've seen, even in the pre-generative AI era, organizations with great software delivery outpace organizations without. I've been saying probably my entire time at CircleCI — software is leading the world. Every company is a software company at this point.

An example I used to use for new hires a few years ago was the president or CEO of Volkswagen Group getting fired because of software delays. It's a car company. I own a Volkswagen product, and I refer to it as a computer with wheels at this point. I was on a road trip and it stopped working and it was just like, "No, thank you. Not working today." There's nothing you can do. If reboot didn't work, I had a lot of choice words for the shop when I found out how they did their observability on the car.

That has been true already, and I think this additional acceleration for the haves versus the have-nots — this acceleration is going to spread the field even more.

If you were the slow gazelle at the back of the pack before this, you're in trouble. The wolves are probably going to run right past you, honestly, and move on to the next one. You won't even seem worth their time. But I do think it will spread the field even more because you've got people at the front accelerating so much more, and at the back, people almost slowing down because they're just lost and confused, trying to figure out how to use the tooling.

Rebecca: You bring up cars being computers on wheels. It reminds me of the other day I was backing my car into my driveway, and I have the backup camera. It beeps at me if I get too close to anything. My kid was with me — he's 12 — and I was like, "do you know, I had to learn how to do this without a camera?"

And he was like, "How? How is this possible?" And so I am now committed to covering up the camera in whatever car he is driving as he's learning so he can learn to back up the old way.

But bringing that back to AI, you could probably see where I'm going. What is that? I don't know how to back up a car without my backup camera.

Rob: I think we see bits of it already in inexperienced developers who are maybe transitioning to software development and sort of using these tools as a crutch. Now, did that already exist with copy and paste from Stack Overflow? Probably. But you can copy and paste at a shocking rate with code generation.

There's a really interesting question. I don't even know what my perspective of the answer is about fundamentals and core understanding. I saw a paper really recently, which I can't quote because I can't remember where I found it — I'm going to try to dig it up — illustrating that more senior developers had higher acceptance rates on their work generated by LLMs because they knew more about how to think about breakdown, structure the request, structure the unit of work, in a way that an experienced software developer knows how to do.

It's the same reason they're productive when they build on their own. They know how to break it down into pieces and build the pieces, test the pieces. So they're just getting better output.

At the moment, if you're building the cool prototype, it doesn't really matter. But if you're building systems to scale, to evolve, then you're going to have to understand how they work today.

Galaxy brain far out, I have no idea — do we still write code? At some point we are asking a computer to generate a human abstraction over instructions for a computer. There's some interplay that is about human transition and metaphor and clinging to metaphors that maybe ends up being less valuable over time, but I think it'll take us a while to get there.

I'm not 100% certain. I do think it's easy to just accept, accept, accept the changes and not really know what the changes are doing. But it's not long before your changes are wrong — not massively wrong, but just wrong enough to be broken. If you've been accepting for three hours — click, click, click, click, click — and then you have to figure out which of all of that broke... I hope you committed between each change. I hope you know how to use git bisect.

It's so funny to me because git bisect is a fantastic tool that almost no one knows how to use properly. But maybe those will be the things that come back. Maybe the craft changes, but you still need to understand the pieces of it. I'm not really sure.

Metaphorically, I remember having a discussion with someone about a database system that we were running on top of AWS or something like that. I said, "well, if you think about it, this has to happen and therefore this has to get loaded from disk, and that would be when this slows down."

And they said, "are there disks in the cloud?" And I was like, I don't know what to say at this point. Yes, you click the button online and got a computer, but it's a computer. Sure, it's not platters, there's SSDs, but they still have slower load times than CPU cache. There's only so many ways to build this stuff.

Having — when you push cloud computing... we're big AWS customers. We push the bounds of AWS. We do things where we hit the physical limits of what it's capable of doing and therefore we have to understand those things and optimize for them.

If you're building systems at that level of scale and complexity, you will need to know a little bit about what your code does, whether or not — even if it's all written by a machine into machine code. Knowing the physics, the actual fundamental limits of the universe and how it operates and therefore what you can achieve, is important.

It's a super interesting question. How do I tape over the backup camera so that people... I heard someone give a talk where they said that they talked about an organization that had a three or six month — when you join, you have to work without AI long enough to understand how our systems function so you don't just start dumping stuff in because we need you to have that context.

But you could think about that in the context of a new developer. And then how long is that information and knowledge going to be valuable? I don't really know. I'm a fundamentally curious person, so I like to understand how things work. I'm not that interested in what's the shortcut.

Rebecca: I would also — I love code archaeology, figuring out how does this work, how did this happen. AI was really helpful for that, for just asking questions about your code or getting it to write code that answers questions about your code.

I see both sides of that. If you don't give me that for the first three months or six months, in some ways you're holding me back. In another way, you're ensuring that engineers can still engineer.

I was asking Claude — I'm like, "Claude has access to this. Hey, how does this work? What does this thing do? How does this work?" And it was fantastic. Then I said, "what am I doing?" It keeps giving me code samples. So I switched to Claude Code and I said, "hey, can you just do this for me?"

And it went really badly. Maybe I'm one of those junior engineers who can't get a good PR, but the explanations of why it was doing what it was doing was enough to guide me on the right path. It was a complex piece of code. But yeah, way easier than "I wish there was documentation out there for this."

I think a lot of things are fundamentally changing. Building understanding, super helpful. But if you're shortcutting and always looking at the tip, using the backup camera — and to be clear, in California, they tape over the backup... oh wait, no they don't. But if you look at it, you automatically fail the test. So you should definitely go and turn it off.

Yeah, I think having fundamentals is a better way to deliver great software with the advanced tooling. Know how to do the basics so that you can apply the acceleration of the tooling. Still feels right to me right now.

Rebecca: It has been so great to talk to you about this. I love this exchange of ideas and metaphors and all of that that we've had during this call. It's really interesting to talk to another leader in this dev tool space because I think it is bearing the brunt of whatever is happening right now.

I really appreciate you sharing your thoughts with us. I hope to stay in touch because it sounds like some neat things are happening and possibly very relevant to our world.

Rob: Absolutely.

Rebecca: And that's the show. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform trusted by some of the best software companies in the world. See you next time.