GitHub Workflows Strain Under AI Agent Development

Hey guys, thanks for the throw. We're here with Robert Whiteley who's the CEO of Coder, and we're having a little chat about our existing infrastructure that we rely on for code repositories, AKA GitHub, and well, there seems to be a lot of issues lately, and they span everything from security to scalability. So let's dive in.

Robert, welcome to the show. Yeah, thank you. Thank you for having me.

From your perspective, what is ailing us as it relates to GitHub? We kind of saw some outages recently, and I guess it got to the point where basically every developer got a day off for all intents and purposes. And the other side of that is, there are security concerns because, well, malware is starting to show up in all these repositories, and people are concerned about where that gets into their software supply chains, and there's more attention being paid because, well, we got all this AI stuff that's going on, but walk us through where are we on this journey, and what do we need to be thinking about?

Yeah. No, absolutely. And you definitely hit the nail on the head.

First of all, I love the concept of a digital snow day if GitHub is down. So I think first of all, GitHub was built with human workflows in mind, and so it worked and scaled wonderfully for decades. But now we're at a point where I think Git as a technology or a forge, a source repository is still correct.

It's just the platform on which it is hosted or built now needs agentic workflows, not human workflows. And the difference is volume and velocity, right? So just the sheer volume of code commits, pull requests, issues is going to skyrocket as well as just because they're smaller, and tend to be the atomic unit is going to be smaller.

There's going to be coming very fast and frequent. Agents iterate faster than humans do. So to me, that's the why now that this is suddenly cracking.

The security one is, I think, an issue that has been bubbling under the surface, and so there's nothing specifically that has broken other than just with AI, we've scaled the speed and cleverness of which bad actors can do bad things, as well as just normal, stupid intelligence. I fat-fingered something, a mistake, something that creates outage. Again, now we just have a far larger population of entities making those types of mistakes.

Well, it also seems that GitHub itself, with things like actions and just the way the workflows have evolved over the years, it's gone from being a place where I quite literally stored code to it's now kind of an integrated element of my DevOps workflow, and as its role evolved, I don't know if it was designed for that in the first place, and it's just kind of showing its age. Yep, exactly. I think, really the utility of GitHub increased with actions and the ability to more integrate it with CI/CD, so that I could use it as an event system triggered on code changes.

As the world moved to software, it was great that my software repository could kick off actions. I just think that if you could do it all over again, as we've seen with alternatives coming out, you wouldn't do it based on a web hook-type architecture. It's just not scalable for the sheer number of things.

And so basically, we just wired way too many things into GitHub. It became a critical dependency, and the technology choices, which were right 10, 15, 20 years ago, are not necessarily the right ones for just how much we require to take action based on code. Other people would say, be that as it may, we're kind of stuck with it, and there's no way out.

So, what is to be done here? Yeah, and I don't want to belittle-- It has an incumbency. It literally holds a lot of the world's data, and so that has value as well as intrinsic mass.

I used to work for a company that stored its code in Mercurial or Mercury. There are other alternatives out there, but I think the community just became familiar with GitHub, and so that is an advantage. Enterprises don't love change, so you have a window in which you can, I think if you're Microsoft, hold on to that.

I think the challenge is Microsoft, like everyone else, is coming to the realization they probably need to refactor this from the get-go. It's not a let's keep bolting changes to GitHub. It's probably a rethink.

And so at some point, if you're an enterprise, you're going to have to rethink all your workflows in the agentic era and the systems that support it. I kind of liken this to cloud native, AI native, the equivalent. Originally, we just lifted and shifted things to the cloud, and then we realized, oh, that's expensive.

It didn't solve the problem. It just took the brittle process and made it break faster because now it's faster in the cloud. We're having that with agents.

We just took our old human workflows, lifted and shifted them to existing systems, didn't change the workflows. People are going to reimagine things in an agent native way, just like we reimagined architectures in a cloud native way. That's when I think if you haven't been thinking about this source forge and GitHub in particular, you're going to be very sorry because that's when you will hit all of these bottlenecks at scale.

There have been some efforts to re-engineer Git itself, the protocol for scale. It seems like there's a lot of individual efforts at this point. Is there going to be some consensus on how to go about doing that, or are we going to see Git kind of fragment itself?

Yeah. Probably the latter. Also what I think is fascinating, and we see this inside of Coder, we see this at customers, the agents themselves may choose to solve this problem.

There is a world where human decisions, human tool selection, is fading, and now, if an agent can easily discover a new tool that does the job better, it will, and it will scale that. And so I think this, let's just keep changing Git because everyone knows Git. A lot of that was predicated on the fact of, oh, changing human behavior on a skill set that is basically standardized.

Well, what if skills can now exist as code? What if workflows can exist as code? I can swap tools out and mass propagate the knowledge of how to use that new tool.

So I think for the first time, it's becoming logistically feasible to rewrite protocols, rewrite these kind of systems. I don't think Git is there yet, but it's certainly an interesting next five years where a lot of this stuff will get reimagined and probably refactored. Do you think as that occurs, maybe we're on the cusp of something that feels like a renaissance in DevOps because we are going to re-engineer these workflows, and today we have AI agents that are banging on pipelines and repositories that weren't designed for that.

And so has the time come to kind of revisit this with what's fit for purpose and what isn't? Yep. I absolutely think so.

And again, I think I'm a big fan that history is just repeating itself. It's just happening at different layers. And so I think when we first went to the cloud, the atomic unit was a workload.

It was an application. Now the atomic unit is just down to the code level. And so everything we know from cloud and DevOps is sort of the practice in my mind that grew up around, well, what can we do now that this stuff can be mutated and moved and is fungible?

We're going to have that. So whether you call it GitOps, AIOps, DevOps, whatever it is, it's just going to be carrying those principles further and further down. The other way I think about it is this is just shift left in its ultimate incarnation, where we just keep shifting things closer and closer to the thing that writes the code is now responsible for operating it, securing it, storing it, as with Git.

Do you think as this all kind of comes to a head, we're really going to be, to your point, the SDLC now operates at machine speed, and how do we mere humans keep up with that whole concept? Because the whole process of coding, and we've already seen accelerate it, but it seems like we're going to see coding, testing, security reviews, and deployment converge at a machine speed. So how do we as humans kind of manage and observe that?

Yeah. You're absolutely right, and if you're not even on the forefront of using agents in production, just somewhat comfortable, you'll already be familiar with the fact that agents spawn agents and parallelize work very well. And so to your point, things are happening at machine speed that becomes impossible for a human brain to keep organized.

And so I think we'll become orchestrators of orchestrators, those being probably higher intelligence agents, and they're spinning up task-specific or even process-specific agents below that. And so as all that speeds up, the biggest implication to us is, first of all, I think it's an up-leveling to softer skills. Every IC is now a manager.

I have to think about how I'm going to manage my fleet of agents, and that is not traditionally the skill set of a software engineer is to have a lot of those softer skills. And so to me, that's going to create an interesting upskilling moment. But in general, I think what's going to happen is we're just going to end up in a world where...

Sorry, this is going to go a little out on a limb, so pull me back if it's not interesting. I think what's going to happen is there will be fewer software engineers in the classic sense. And those will be the ones that stay behind in the operational centers monitoring all these agentic workflows.

But I am not a pessimist that thinks software engineering as a discipline is going away. I think what's going to happen is it's going to embed into the business, and we're going to have different business units that have resident, I hate to say the phrase vibe coders, knowledgeable software engineers that are more in tune with the business than they are any one language or skill set. And their job is to sort of build that locally, and then we have an uber large platform team that's looking after the actual systems and fleets and agentic choices.

And so we'll distribute the skill set out. And the last thing I'll say that's sort of changing an implication here is I do see in a lot of our customers, just for context, we tend to deal with larger enterprises, so think sort of Fortune class They are hiring fewer software developers. They don't necessarily are getting rid of anybody, so they're just sort of capping populations.

But they're then empowering many other types of knowledge workers to have access to Claude Code or Cursor. And so there will be far more software production in the world in the next couple of years, but it'll just be happening in a non-traditional centralized sense. And that's why I think this is going to be both exciting and terrifying.

Oddly enough, in that scenario, does the software engineer become automated, or they may become more crucial because they're essentially the individual that all these workflows are revolving around? I think it comes down to the nature of the application. If it is a customer-facing, revenue-generating, business-critical, you need a software engineer, even if they're just outsourcing the work to agents, as the person that knows how to break requirements down for the agent, check the agent's work, review code.

So I don't think the art and science of software engineering for really critical software is changed fundamentally. It's just the speed at which we can make it has changed fundamentally. The difference in the distinction I'm trying to make is all this vibe coding, it's really just business automation.

It's I'm trying to solve a problem, and I can now create a lightweight dashboard application that automates it. That stuff tends to be somewhat disposable. If it lasts six months, great.

If it keels over, the business doesn't die. And so I think that's where the software engineering skill set is overkill, to be honest with you. And I think we'll see this sort of renaissance of good enough to be dangerous, where I can describe the problem and iterate back and forth with an agent without having any idea if what it's producing is high quality or not.

I just think that how do you govern that? Do you, as an enterprise, have the ability to distinguish between those two, and how do you kind of equip it? So we'll go through a little bit of a teething process, but I do think we're going to see very different categories of software that get created.

Last question, though, but GitHub kind of rode the rise of the cloud. So it created this SaaS environment, and we all put our code there. As we move to this agentic engineering mindset, is the repository going to be this big central service, or are things going to wind up more federated and there'll be micro repositories in different places along the way, and some of them may even be out at the edge where the applications are running, and things will just become a whole lot more distributed, and we'll have some overlay for managing all of that, but the repository itself, we might not recognize it as some single entity?

Yeah. Fascinating question, and I think I'll answer it in two folds, with the second fold being just my conspiracy theory. So right now, there's an interesting trend towards centralization.

A lot of my customers talk about sovereign AI, where they want to own their data, their code, their inference, I despise the term, but their alpha. And a lot of that's competitive advantage. It's regulatory in nature.

It's even political in nature. So to me, I don't think we're going to see this immediate dispersal for technological reasons because the countervailing trend of, "I have to control this," will sort of rule the next couple of years, in my opinion. But we always know that centralization and decentralization is a pendulum.

So we're going back to mainframe era, and we'll live there for a while. Then we'll go back to distributed systems. And with that, I think forges and source repositories will decentralize.

Ultimately, I want it to sit closer to the intelligence, so I'm not paying this massive round trip latency as the agent iterates on it, which we do in GitHub today, and that's why those web hooks are just so painful. So to me, that is going to be a trend, but it'll be a while. And so what I think we end up with, and this is where my second fold, this is my tinfoil hat, I think we're going to actually go away from the atomic unit that we care about not being code, but context, chats.

I'm going to want to store, fork, version, recreate chats. The source code is pretty cheap, and I can probably recreate it in minutes. And so I don't really care if the repositories live out at the edge as long as I have an immutable version of the chat itself.

And so I think we still end up with some things that we want to hold near and dear, which tends to favor centralization and security. It just might not be the bits that make up the code. It'll probably be the bits that made up the context for how that code was created.

All right. Folks, you heard it here. GitHub, hope for the best, then prepare for the worst.

But also take heart in the fact that we are going to reinvent the entire software development life cycle. We just don't know exactly how that's going to turn out just yet. Hey, Robert, thanks for being on the show.

Yeah. It's a pleasure as always, Mike. Thanks.

All right, and back to you guys in the studio.