# Scaling AI Agents: From Editor to Infrastructure

**Podcast:** Dev Interrupted
**Published:** 2026-03-10

## Transcript

Hello to our listeners and welcome back to Dev Interrupted.
Right now, a lot of engineering leaders are stuck in the same loop.
They roll out AI tools and they see promising demos, but when they go to measure productivity, the numbers get fuzzy and the organization quietly drifts back into business as usual.
Sound familiar?
James Everingham, however, has lived the opposite story.
After nearly a decade at Meta, including leading Instagram engineering, he was pulled back to help run DevInf, a thousand person org responsible for the internal developer experience of 40,000 engineers and technologists.
There, he discovered that the real gains come from when you stop thinking about AI as an authoring tool and start treating it as sentient fabric across your entire SDLC.
And that's what we're going to talk about today, because internally that work became DevMate, an agent platform that went viral inside of Meta and grew to the point where its agents were submitting 50% of all diffs.
And now James is taking those lessons to the rest of the world as the CEO of guild.ai, where he is building enterprise infrastructure for AI agents so that every engineering org, not just metascale companies, can centralize and orchestrate and safely scale their agent workflows.
This is something we've been talking about quite a bit on DevInterrupted.
So we're really excited to dig in.
And James, welcome to Dev Interrupted.
Thank you so much for having me on.
I'm excited to be here today.
Great.
Well, let's go ahead and jump into talking about that mental transition, uh, the one I kind of opened with here about moving from the idea of AI being an editor, a helper to being part of the fabric that you work within.
Um, you know, when you were leading Dev Infra, you realized pretty quickly that like, you know, autocomplete and just finishing your idea of what to implement is not where the biggest wins are.
You went for these larger leverage opportunities within the infrastructure beyond the editor.
What was what was that realization like and what led you to go there?
Yeah, sure.
I think, you know, when we first started, look at, you know, we were on the same path as everyone was trying to accelerate developer productivity using AI.
We started with the same tactics that we saw, such as uh, I would say the in the in-authoring experiences.
You see the cursors and the copilots out there, which are uh autocomplete.
These have evolved to much more than that, but that's where we all started.
We had an advantage there where we were we owned all of the internal tooling.
We owned the we had we had to build our own editors.
We had to build our own source control because the repository was so large.
It wasn't that we were uh an NIH company.
It's just that uh infrastructure is so vast and large, these tools just wouldn't work.
Uh so the advantage of that though was that we got to measure and experiment quickly with a very closed economy of developers.
So we could learn pretty quickly.
We did learn that, like, hey, these tools like Cursor, which we basically came pretty close to feature parity with internally with our internal product called Code Compose.
Um, you would get a certain level of productivity more with the junior engineers.
Um, and actually surprisingly, some of the very senior engineers, but the the bulk of the engineers in the middle weren't actually uh, it wasn't moving anything meaningful.
And you know, that's a whole conversation itself is like what is moving something meaningful actually mean, which we put a lot of thought into as well.
Um, so we experimented and eventually uh we we started trying some different things.
And one thing that we did, we had this realization that, hey, you know, AI is a very powerful tool, but if you actually move some of this new agentic behavior closer to your source control system as part of the infrastructure, you get a lot more impact and you can do a lot more interesting things.
You know, source control is like the canonical source of truth, like your teams, your tools, everything connect to it.
There's your code, your history.
Um, and if you can intercept some of those tool connections and invoke agents um, and uh you could start doing some super interesting things.
You mentioned this opportunity you have that because you owned all these different parts of the stack and you had everything custom built, you get these really amazing opportunities to slice and dice and examine.
And that's like a privilege and an ability that like not a lot of orgs have to like the level of granularity that that they get.
And so I think this oftentimes muddles the process of trying to experiment and measure the impact.
Like, what would you what would you say to somebody who is working within an organ, doesn't have that level of detail and slicing their whole top-to-bottom system?
Like, where should they start to try to zoom in first and look at what they can get their hands on?
That's a good question because like it's it's I think that's one of the things that the industry is also struggling with right now is like where do you even start?
Like, you know, uh a lot of the companies that we talk to now outside of Meta, that's the first thing that we come across is like, hey, you know, we're all getting pressure to to do more, to develop faster and things like that, but it's not even clear where to start.
So what what we found, the formula that we found inside Meta that really helped kick things off was that we had a centralized place where where when I when I talked about this platform, which was DevMate that connected to the infra more, there was also a centralized place where engineers could go and actually see what agents were there, what what was working, what wasn't, and they could build on them, they could view them, they could dig in, they could branch them, they could create their own space on those.
And and that was a great starting place.
You know, as engineers, you know, I, you know, speaking for myself, I was a better like thief than coder.
Like I would go look for something that would uh that would do kind of what I want.
And then like I would try to get that and wrangle it into something that would work for my specific thing.
And I would learn along the way.
And if it didn't ultimately work, I'd have enough knowledge to go build something new.
And I think that's not, I don't think I'm that unique.
I think a lot of engineers work that way.
And so when we had this centralized surface, it was a clear starting place.
So, you know, for companies that are outside Meta is like one, you know, where do you go?
Where do you go find this clear starting place?
You know, where do you go and point at things that are working outside?
And, you know, we're getting better.
It's like becoming more clear what works in the industry now.
You're seeing a lot of more uh referenceable uh pieces of technology that are actually doing real things.
So I think this will become less of a problem over time.
But right now, you know, it's it's not clear where to start.
And it's not even clear what, you know, the holy grail of metrics is developer productivity.
Like, you know, right.
Um, is it lines of code?
I I don't think it is.
You know, some of the most productive developers delete more code than they create, right?
So um is it feature velocity?
You know, what is productivity in your company?
I think another place to start is figuring out and and getting pretty pretty detailed on what that actually means in your company.
You really hit on some really amazing details here because focusing it on the first idea that like you have to understand what matters to your company and or your organization before you can even go out and hunt these things.
And the idea that also of, you know, always being a better like thief, the like a cre original creator, I totally like that resonates with any kind of engineer.
We don't wake up and we're like, oh, I want to rewrite grep today.
Like we go and find the tools that help us get the outcomes that we're looking for with software.
So, you know, I'm always looking to leverage and learn from other people that are playing within the same space.
So what y'all did was really smart.
You created this like a corral, basically, where all these agents and these workflows and these experiences can go, folks can go and learn and experiments, fork and then standardize.
That's kind of like you get to that core of that like idea of a fabric where the agentic work is happening in your infra.
So, you know, as part of that too, I bet that you got a really great glimpse into emergent kind of solutions and agentic things that you probably definitely didn't have on your radar or didn't think about.
But because an engineer within your org was empowered and was and had this place the share, that stuff got elevated.
Like, what were some of those that stood out to you?
Yeah, you know, you you hit a very important point is like, you know, one of the things that was interesting in dev infra is like we would get stuck in thinking like, what are the best things that we can build for developers?
And what we found when we pushed the tools to the developers themselves to solve their own problems, the best things were coming from the teams outside of develop devra.
And, you know, so I think like the measure of a successful initiative or a successful platform is when the ideas are coming from your customers and you know, and they're able to build on it.
So a few examples of that were one, we had something called if risk score, and it was uh using an LLM in a rather novel way.
Um, and this was open sourced actually last year, where it would measure the amount of risk that a disk, a diff would have when you push it to production to crashing the system.
And of course, like many companies, we freeze at Meta, we would freeze the code base at like December 9th through January during the holiday, because that is where the most traffic is a very important time for the company.
Um, this allowed us to start removing that code freeze.
Like, and uh the way that we the way that these this happened wasn't by saying, go build diff risk score and do this.
It was a challenge to the company saying, how do we eliminate code freeze?
And then the engineers came and built these tools to start doing it.
Um, so that's one example.
Other ones that just sort of organically popped up that I thought were amazing was this incredible onboarding agent that an engineer built.
And you know, once again, you know, I have a friend that I keep re-quoting saying, you know, great soft building great software is an act of empathy.
Um, and this was no exception to that.
It was it was an engineer that was trying to familiarize himself with a code base to be productive, and he'd build an agent to go help him do that.
This agent, I'll explain it a little bit.
Like back at Instagram, which you mentioned, if you brought a new engineer in and you said, Hey, I want you to work on these specific camera filters, that engineer might take a week just to figure out where those files even are.
And um, it's it's it's complicated code base and process.
The onboarding agent sort of made the source control base sentient in a way.
So you could ask it questions.
You could say, I want to work on these specific camera filters.
And it would say, Well, that's these files.
Would you like a system diagram?
And it would draw you a system diagram.
Would you like to know about the history of this and why things are done?
And you could have a conversation with the source base, and this onboarding agent um would effectively make the source base onboard the engineers uh directly.
And we had measured something called TTFD or time to first diff.
And that was like, how long does it take to get an engineer in and get them to submitting their first diff?
And this agent alone was decreasing that um pretty significantly.
And at scale, that's a lot of manures reclaimed in a large workforce.
So those were just a couple.
Hundreds of these popped up, things that I had no idea, um, like would never have imagined.
It was really fun to watch.
That onboarding agent is a really powerful uh unlock because what that represents actually is like a huge amount of downstream leverage that you were able to unlock as the person implementing that kind of infrastructure by creating a space where other people could create infrastructure and save themselves time.
Someone else then created a tool, a system that then saved everybody a ton of time.
And that was a leverage beyond your initial leverage.
And that's what happens when you create these spaces where folks can solve the hardest problems within your engineering org.
And I think like something like time to first if is really critical for huge code bases.
And I know a lot of our listeners who work on a huge code base is really identify with that pain, especially when it comes to bringing in folks who are trying to have instant impact.
I think that like in in this world you're describing this as the ideal, right?
Where, like you said, your customers, your stakeholders are coming to you with things they want to they want to do and they're building it on your platform.
But you know, sometimes that script is not necessarily what is happening or unfolding within an org.
Sometimes you get more top-down mandates and things from leaders within an organization about how AI will be used or what our policy around it is, or a top-down goal that maybe doesn't really tie that well to like technical throughput for engineers.
So, you know, what do you think about that approach?
How would you uh advise somebody to navigating that as an engineering leader to try to really unlock value?
Yeah, sure.
I, you know, I think that I'll make, you know, I've I've been not um quiet about this.
I do get a little a little frustrated when I see uh CEOs and leaders saying mandating their team to use AI for productivity.
I think the best developer tools, like you have to earn the usage.
Now, like developers are smart, they're you know, they want to do good work, but they're also, you know, they have a set of tools that they've become very proficient with over time.
And they take some convincing, right?
Now, the the way to do that, in my opinion, isn't to mandate, like, hey, you all need to use these specific tools.
I think what we ended up doing that that that really helped was to put business challenges out, one to your organization that forces them to think differently.
Like, for example, another one that we put out there in DevInfra is can you make self-healing fabric?
Can you make it so that what uh if the system does crash, you can identify it automatically, you can write the code to fix it, you can write a test case to prove that it fixes it, you can run it through that loop until it finds it, land it responsibly, um, and minimize uh the impact radius of that outage.
When you start putting these types of challenges out, like there's not many other tools that you can use.
You're sort of forced to use AI to do that.
So that's just one part of the equation.
Now, AI is very good at doing simple things.
It's it's a little more challenging to get it to do very complex algorithmic things, right?
So, like getting the uh a product team is a lot easier uh to prove uh utility with these tools than like the bowels of a uh a VM or uh languages or a kernel team, right?
Like those are very hard things to do, but you can still put challenges out there for those types of teams.
Uh um, you know, can you optimize compiler output with an LLM?
You know, can you change the spec of a language to uh actually make more uh an LLM can more accurately build the right code, you know, things like that.
Once you get that, the next part of it is to get some senior engineers who who have had uh success with it, and they should be your evangelists.
So uh we luckily at Metal, we had these amazing internal uh workplaces where everyone could communicate openly to the company.
And we had senior engineers that were like, look what we just did.
We did this with this agent.
And the other senior engineers then would be see that and they would they they would they would want to actually try something or it would spur something where they're thinking, and that organic earned usage is what really ended up moving the dial, right?
Like they're going to use the tools if they can help them, but you know, the early tools, they're getting better, don't help every engineer.
Some of them slow them down.
And so you so the mandates are a little a little a little misguided, if you ask me.
Yeah, and that's really good advice for how to level set it because you take that top-down kind of mandate and you find a way to turn it into a collaborative space where those organic gains can surface.
Like if you have a top-down mandate, okay, then use that to establish a recurring learning and sharing meaning, and then use that to incubate these best ideas that maybe in an ideal world, like with the one you were describing at Meta, like you would it would be evolving and happening in like this share kind of agentic mesh or like a corral of different agents doing different stuff, you know.
So within that too, I think once you get to that point and maybe you're in a position of having to prove uh value back in like a top-down kind of way, once you have that kind of muscle built, then you can start exploring things like um like that you said, like getting rid of your code freeze is a great example.
I'm sure there's like a lot of uh bandage or like back of the room, back of the office kind of issues that like any team could think up and and and and and tackle.
Like, are there any other like big ones that come to mind for you that you'd recommend people like every org has this debt?
Go tackle this debt with AI and prove your worth.
Yeah, I think that look, testing is one that everyone does is test cases, and you know, you can have a hundred percent test coverage code-wise, but humans actually uh will end up using the products in different ways where different code paths get exercised, and you can never uh find all of the problems.
But like, you know, one challenge we put out there is can you build a testing harness that would simulate how a human would actually use the software?
Um, and that's something really good that an LLM can do, it can mimic behavior.
So instead of saying go and automated test suite, test this image, test this filter, test this, you could basically give it a script and say, you're a user, you're walking down the street, you take photos of this, you wonder where there's restaurants.
So you look those up, and you can describe a user scenario and then you know, have an LLM go replay that into your software.
And so, like that was another example.
But we we had a lot of big challenges, like eliminate code freeze, uh um, self-healing fabric.
Can we expand uh who contributes to the feature set beyond engineers?
Can we go directly to product, to designers, to everyone in the company, people outside the company?
Like, what are these big challenges?
And it's fun.
Like, here's the great opportunity to do with your org that we really just we might have gone overboard at some point with it, but look, you know, we get to write science fiction stories about like how development's gonna work in the future, and like get your team to do this.
Go like, go write a science fiction story about like what development's gonna be like in five years and go make that happen.
Um, and that's where a lot of these ideas came from, you know, was people just dreaming and uh thinking about like where their pain is specifically and coming up with these novel ideas.
I think that's a fun way to reframe it.
It's definitely how I go into building things these way these days.
Like you go in with all this baggage and expectations about how an app is supposed to be built, how it's supposed to be delivered onboarding, what the experience is like.
And we do, we get to live in this, like you described, like a science fiction world where you can throw that away and you can rewrite what it can be.
None of us have the language or like the knowledge to know what these will, these kinds of tools and apps will evolve into.
Everyone has their take on like what's gonna happen to Apps Linux in the world of AI, right?
And so, like in in this world, like what you said is you're going out to solve a pain point, a problem.
Like, we become engineers because we want to have like a lot of impact.
We want to create technology that changes the world for the better.
And I loved what you said earlier about uh this quote that you say about building great software is an act of empathy.
Like, I really relate with that.
I think it speaks to the core of what we all do as engineers about using technology to address a problem and helping other people.
Putting like putting yourself in other people's shoes is like really fundamental part of engineering.
And I think that like AI, even in this case, can be a huge leverage that engineers can use to unlock that.
Yeah, absolutely.
I mean, that that is part one of the things we've always tried to do, or I've always tried to do in my companies and organizations is put the software between, you know, make sure my team is somehow using the software, even if it's not relevant to them, figure out a way to force them into the software.
If they're not using it every day, it's just not going to get better as fast as if they were.
So, like, uh always find a way to get your developers um to feel the pain that your customers will have.
Yes.
Bringing them closer to the problems and getting them in the conversations.
That's where you get really great velocity on engineering.
We cover that.
We cut we talk about that a lot on the show.
We with engineering leaders who have um engineers who get set really close to the problem and talk to customers.
I think that's fundamental, especially now to being able to deliver software value.
Um, and just before we move on, I also just want to bookmark what you said, just point people's attention back to the idea of the user intent-based testing method that you can do now with AI, where you can literally, you don't have to write necessarily the super strict unit tests.
You can have a more abstract layer of tests too, where you point it at your website or your API and you tell it to do something.
Can it figure it out?
And frankly, that's the kind of unit testing that I think more org should embrace because agents are becoming their primary consumers.
So just something to really um point towards.
I think that's like again, going to the science fiction world.
That's a that's a that's something that you would never have optimized for a few years ago that now is a major win that doesn't have a word for it yet.
So uh that's the kind of challenges I think we're up against.
Yeah, totally agree.
It's like it makes me think there's probably a whole business just to rewrite like chaos monkey out there, right?
Like you can you have persona-based testing systems, like you know, and uh there's probably a whole opportunity just there.
Yeah.
And in fact, speaking about like the the chaos opportunities, I think like AI on the ground with a lot of engineering orgs, there's a lot of like business risks involved with like runaway costs and security and IP and also just like fragmentation and all of this, the huge risk of all of this stuff getting kind of siloed.
So, like what does it look like from your perspective as a leader in this space, like when you would talk with other folks and other engineering leaders about how they're kind of taming this within their or like what do you see?
So I think that's the you know the next big thing, the next big challenge.
You know, this industry is evolving really fast.
And you know, one way to think about it is is like if 2025 was the year of ibe coding, like 2026 is sort of the year of agents, right?
And uh what this means is that we're seeing a lot of these reasoning models and different architectures that are now not just being part of an autocomplete, they're becoming a fabric of the company, right?
So you need a control plane to be able to manage these.
And what is a control plane?
It's a piece of infrastructure that allows you to govern these things.
You need to be able to understand what these agents are doing in your infrastructure instead of just give them access to everything and let them YOLO it, you know, that's probably a great thing.
I doubt your SOC2 sign-off person will be happy with that.
So the ability to deploy these, roll them back, give them access to specific parts of your infrastructure to be able to log and see what they're doing, to be able to like understand the costs of what each of these are doing.
This is the challenge that like is that we think is coming up.
This is what we're seeing.
This is a problem that we're hoping to address with guild.
Um, and uh uh that that's sort of what we believe is the next challenge here.
I firmly believe that like right now, if you look at corporate infrastructure, not even just software development, you know, it it all looks you have servers, you have all these internal web applications.
I think the future of that is gonna be have thousands, hundreds of thousands of agents.
They're gonna be doing all types of really amazing things in your infrastructure.
So, you know, understanding giving those things control and understanding that is the next big challenge for this stuff.
Yeah, I couldn't agree more.
I see agents and like their impact on this kind of infrastructure almost the same as like it's almost like a TCP IP event all over again.
It's like you genuinely are thinking about how can I pipe all of this intent and impact, inputs and outputs, and weave it all together.
It's a new way of thinking about how information moves within any system that we're all still like grepping around and exploring.
Like the exact pain point you've described is like what pushes developers like me, where I run, you know, dozens and lots of agents in parallel and do lots of things all at once.
Like I moved to a VPS because it just fundamentally doesn't scale in my own laptop.
And why am I in a VPS?
Because my org doesn't have the infra necessarily.
I it needs to meet me where it needs to go, it needs to be.
And I know a lot of engineers sing that pain and have built their own version of this VPS thing that I do too.
And it's like you ultimately remove these barriers that let you move fast, but then you're running so far ahead that like your entire org can't keep up, and you end up kind of building these in the middle pro uh solutions.
And that goes back to the science fiction reality of it all.
Like it's not actually that scary because you're running so fast that you're inventing the ground in front of you as you run, but it's still solid ground.
But ultimately, how can you you can't build on that?
That's where things like guild, I think, come in and really offer this full suite solution.
Because like if you're like a 10x or 100x engineer and you're having a ton of output, like you want a way to distribute output.
You don't want to be the thousand X engineer in your team and the only one who's just like Houdini can just do anything with AI.
You want to distribute it to everybody, and to do that, you need the platform, you need the infrastructure.
And you want to feel safe, right?
Like traditionally, you you know, you there's been this trade-off between like moving fast and then having things that are like secure, properly governed, and everything.
And we don't think that you should have to make that trade-off.
We think that you should have an environment, the future development environments are going to have the guardrails and necessary to protect engineers.
You know, we're kind of uh a risk-taking bunch, right?
Like we just saw this with OpenClaw, right?
People, yeah, I'll just give it access to everything.
And probably there's like passwords and security keys and malware being installed.
Like that's that's bad enough on your personal laptop.
But like as soon as one person does that on a at the corporate level on the infrastructure, that's pretty that could be pretty damaging.
So like that's the thing to be concerned with.
That's one of the things that like needs solidly addressed in the future here.
Yeah.
So like it solves one part of it is the context and just like the environment sharing kind of problem.
Another part of it too is the auditing, the security, the awareness.
And when you kind of build this, it's it makes me think of like when you made DevMate, it was kind of like an internal agent, almost like an app store kind of deal.
People could go and like search around and find different solutions and fork them and change them.
Like, is that how ultimately this same kind of platform works within any other org that you're envisioning?
Like, oh, people can come in and spin up and create these workflows that all live in this like shared internal like ecosystem.
Yes.
Yeah, so yeah.
If you're central, like if you sort of pull on the thread of a control plane, you have this centralized piece of infrastructure that's doing that.
It's like it's um it's providing access, it's um it's providing context in a way that makes sense on a per team or per company level.
It's providing credentials, it's providing session history.
Uh, you know, you need to understand when something goes wrong.
You need to quickly be able to go in and debug it.
So you need all of that.
And part of when it's centralized the opportunity is like your agents are centralized.
So very much like you see a managed software center and an enterprise for what software you know you're allowed to install and not, we're gonna need that for agentic infrastructure.
And like your security teams gonna want to go through and configure these things and say what they're allowed to do and help build the guardrails around these.
And that's just not even going to be optional.
I do not see a world where that is not something that is needed.
I can't even imagine that.
Now the next big opportunity is like okay you have these agents just like you have a managed software center, like maybe some of these could be public, right?
And you go and not only can I learn internally what engineers are doing, but I can learn cross company.
And this is sort of what happened with GitHub, right?
Like you can now go and see public repositories.
In guild an agent's like a repository and there are workspaces and workspaces are runtimes and runtimes have access and there's a reasoning layer and an execution layer and there's execution controls.
You know, like you need all of these things, but like we do we do, we're big open source people.
Like our routes are open source.
Like personal routes are open source.
We saw the power in this all the way back when we did Mozilla, you know, at Netscape when we opened that up.
You know, what we put out there was initial one was was wasn't that great, but having the community uh learn and make it better over time, it sort of came the standard and led to even what are parts of Chrome, Firefox, all of that.
We think that's missing for the agent landscape.
And that's something we're hoping to provide.
Yeah.
I mean I I definitely think it's missing in the agent landscape and that you're right.
Someone's gonna have to own it.
I and like it's gonna have to exist there.
I I want to unpick your brain a little bit about the kind of uh what kind of person you think or the group of people do you think does own is it does a that fall with underneath the traditional kind of platform engineering domain that now expands to can include this AI control plane.
Is it a fundamentally different team maybe has a different interrelation uh it's something the brainstorm because just as necessary as it'll be to have that kind of layer it'll also be necessary to have the org to support it.
So what do you think that looks like you mean who owns the control plane um yeah or well yeah I think that like you're going to see a lot of these in the future, right?
Like, I think that there will be ones that are offered by specific vendors, and then I think there are ones that will be offered like companies like us that are vendor neutral, right?
So rather than phrasing it as who who should own it, like I can say some of the trade-offs of the people that maybe shouldn't own it, right?
Like if you have a specific vendor owning it, like they're just by the sheer uh just by the their business or what they're trying to do, it'll probably lock you in and limit you more to their solutions.
So if you're trying to build something that is um picking up the best of all of the solutions out there, you may not want to be locked to uh a single vendor.
I mean, there are reasons you might, but like there are also reasons you might not.
Um and I'm not sure if I'm answering your question.
I may not have understood it.
So please steer Oh, maybe I'll clarify by asking within an org, what's the type of role that you think owns that enablement, that platform?
It's like I I know I see a lot of orgs now with like AI platform, yeah, engineering leaders.
Like, is that who you think owns that kind of activity?
Yeah, I mean, I think like look, there's there's probably more than one org that's gonna own that.
So you have, you know, right now, agents when you're building the way that engineers and and teams are building even uh agents and infrastructure is what we call like single player mode, right?
It's like you have any you have an engineer who's firing up like cloud code, has it running on their uh their their server or even their laptop doing something.
Um, but this stuff needs to be multiplayer.
So like when you're when you're when you're moving to like this type of system, you might need your security team to be able to access and do it.
You'll probably even need like your financial teams to go in and do audits so you can see like your token spend.
So you have a bunch of different um entities in the company that are gonna need to access it in different ways.
So I don't think there's like one single owner.
Like, you know, probably your core infrastructure, your IT team will like set it up and manage that.
But you'll have a lot of people involved in this in order to make it work, especially as scale.
Yeah.
Especially too as you explore it, like you called out a lot of primitives that are needed to make this system work.
Like obviously the storage layer of them, the compute layer of them, the communication layer of them.
And um, it's about understanding which parts of those are are most critical for your organization and which of those maybe you're trying to solve for first, too.
You know, maybe just to just wrap things up to get to so we've we've explained kind of the dream for this kind of platform that we need to build towards and get and orgs should prioritize having that way they can fully take advantage of their AI transformation.
But uh what do you think is maybe the most critical like primitive of the ones that you've called out?
Like maybe what should people focus on first to start getting immediate gains?
Is there like a part of that orchestration platform where you're like, this is the first unlock that you would recommend to people?
Well, yeah, I think that's a really good question.
Like, I think, you know, if I go back to the DevMateX experience, like there, there were some clear agents that were that were that would work across multiple organizations.
So, like, you know, what we're hoping to do is have some reference agents available as a clear starting point, like maybe an onboarding agent.
So you can go and say, wow, look, this is awesome.
This works well.
I just click, boom, now it's I've created an account.
I've hooked it to my repo, and now I have an onboarding agent and I have a centralized place where engineers can go and look at it, add new ones and start forking it or doing whatever they need.
That's what we hope to provide.
But I I always think a place to start for any team is to find something that works.
And you're gonna have to look outside your company and uh and uh and use that as a model.
Yeah, absolutely.
I think it's like in a maybe a previous life, you know, we would go and hunt those like prompts and save them to our prop library where we're all like starting on this like AI journey and you think about oh, what are the workflows I can build to unlock my own kind of velocity?
But now it's just challenging everyone and organization leaders, you know, listening to this to look and model at these kinds of uh workflows that are happening on an org level within other places and be like, how can I capture that and model that?
Um, I think there's a lot.
That's like the next level of unlock that that leaders can gain right now just by paying attention to like these kinds of systems.
Because when you really crack the egg and like you look at it, there are a lot of them are very simple.
They're taking advantage of simple primitives.
Yes, they they are.
And and again, maybe this goes back, and I'm just adding on to an earlier question, but a way to energize your teams to do this is is by putting big challenges out there.
You know, we we tend to, you know, we we see these same patterns over and over.
And the analogy that I use is like I feel like AI right now, when people are trying to move faster with it, is if they're a car company and they said, we want the car to go faster, and everyone just started polishing their part and making it more efficient, putting it back together and saying it's oh, it's going a little bit faster.
You need to completely rethink the car.
And so the way that you do that in a business is not by saying, I want something incrementally better.
You have to put challenges out to your org that are crazy.
You have to go order of magnitude, go to your team and say, we have to 10x revenue in six months, or our CI C D like from land to production is six hours, get it to five minutes.
You know, you got to put these crazy challenges out.
And that is where like you get order, that's where you get order of magnitude, you get evolutionary, not revolutionary thinking in your org.
And it sort of forces the team to use these tools because they need to.
Yeah, I love that frame of thinking.
It reminds me of something I read recently from Claire Vaux, where she said, challenger org to rebuild your entire product from scratch in two weeks.
And then if you can do it, reflect on what that means.
Like it, you have to have these really difficult conversations and challenges.
Um, that really stood out to me.
Um, the advice that you just gave of setting a really huge ambitious goal, I think is the kind of thing that gets people thinking creatively about the tools.
Um, really great framing.
And there's honestly so much that we continue to unpack.
So we'll just have to keep chatting for sure.
But for now, I'm gonna go ahead and say that, James, it's been such a pleasure to have you on the show and to pick your brain about how you think AgenTech engineering orgs are going to evolve and the things that they need.
Uh, but just before we wrap up today, where can our audience go to learn more about your work and guild and and what you're building?
Yeah, absolutely.
Well, you can go to guild.ai, where we're taking sign ups on our wait list right now.
Uh, we are very close to starting to open that up to have people come in and and and start using it and giving us feedback.
And we're, we're we're very excited to do that.
And we can't wait to hear what you build and see what you build on this platform when we do release it.
Because I know it's going to be more than anything we thought internally.
Amazing.
Well, we're gonna share links in the show notes, make sure folks know where to go to check out guild and and see the latest there.
And to those listening, if like you want a deeper dive into the leadership side of AI transition, which is a lot of what we dug into today, be sure to join the conversation in our newsletters as well.
We're distributed on Substack and LinkedIn.
You can find easy ways to continue this conversation with us because James and I are both also on LinkedIn and would love to get your thoughts about what you heard today.
And so thanks for tuning in to Dev Interrupted, and we'll see you next time.
James, thanks again for joining us.
Thank you for having me.
This has been so much fun.
I appreciate it.
Linear B changes that.
Our AI reviews every PR the moment it's created, catching bugs, security gaps, and performance issues before humans get involved.
It even writes the PR description automatically.
Your reviewers spend less time on first-pass problems and more time on architecture and business logic.
Break the bottleneck, see how Linear B accelerates your workflow.