# Terraforming AI Markets: Inference Engineering and Double-T Talent

**Podcast:** Dev Interrupted
**Published:** 2026-05-05

## Transcript

Today, I'm joined by Philip Keeley.
And Philip is the head of AI education at Base 10 and the author of the new book Inference Engineering, which we're going to talk about some today.
And Philip and I, you know, we share a background in developer advocacy and around education.
And developer advocacy itself has always been about empowering developers.
And we've talked a lot on our show about how right now this is something that we all need to rise to the occasion for in terms of teaching ourselves, but also teaching others about the new norms of engineering.
and the way that we all get our work done.
And especially now today, we're certainly starting to see a lot of folks in titles that are more AI native and focused on the AI front that's unfolding in front of all of us.
And so we're going to talk about what it means to be in an AI education role, what that means to uplevel your game as a developer advocate and enter this new world of agentic engineering in the engineer's header here building.
And we're also going to explore a little bit about the connections between.
all of this education, engineering, and product, and how it creates that sweet, sweet motion of go-to-market that we're also obsessed with.
And it's frankly roles as well that, you know, head of AI or at AI education or AI platform, like these are brand new roles, but now they're, in many cases, becoming so essential.
So, Philip, welcome to the show.
We're really excited to dig in with you today.
Hey, thank you so much for having me.
I'm really excited to be here.
Amazing.
Well, I'm going to dive right into talking about your role in developer advocacy.
I'm curious, when you talk about your role as head of AI education, how do you describe it?
What is it that is most important to you?
I have a good understanding of the things I like to do and the things that are valuable to the company, and I just do those.
But of course, you have to communicate to the rest of the organization as well as to the rest of the world what you're working on in a sort of succinct way.
Just like maybe the title of a book is the most efficient version of the thesis of the book, the title of a person should be the most efficient thesis of the value of their work.
What we found is that there are a couple different types of go-to-market versions right now in the AI industry.
One is a very traditional sort of market capture where you're trying to go after existing workloads.
You're going after people who know exactly what they want and trying to move them over to your platform.
The other opportunity, though, the...
potentially more exciting motion, I think, is more of a terraforming market development type motion where you're going out and introducing people to new concepts that they're going to need to learn in the next months and years to effectively do their job.
And you're making sure that from the first moment they experience these concepts, they're thinking about them in a way that's conducive to the way you do business.
So that's really my mission right now is to introduce a bunch of developers to AI concepts in a way that gets them thinking about the problems of inference and the problems of building reliable AI native tools in the same way that we do.
Because if they think about the problems the same way we do, they're going to naturally come to us as the solution.
Yeah, you're actually hitting on something that's really exciting, I think, right now, working in a role where you're kind of educating, informing, and empowering people about new stuff.
That you're just putting new ideas in their head that are going to sit there for a while.
They're going to kind of like you're planting the seed of thought, right?
With the idea that over time, this demand, this knowledge and what people can leverage from it is only going to compound and grow.
So the earlier you're there in their mindshare and you're able to kind of set them on the right path, then the more they're going to like attribute so much of that back to you.
You're kind of part of like the nucleus of the thought, which is like.
Like what you hit on, like what's something that's really exciting right now?
Because it's like, you know, you're putting this new ideas of engineering in their head and then you're seeing how people are able to run with it.
Yeah.
And you can do that from a sort of content and marketing perspective.
You can also just do that on technologies like, hey, everybody is still using the OpenAI SDK, even when they're not using OpenAI models and they're still using the same OpenAI output format, just because that was the original industry standard from a few years ago.
Like that's developer mind show as an example.
There's a lot of advantages to being a sort of first mover when it comes to capturing that mind show.
Of course, you've got to do a lot of other things to turn that mind show into business value.
Like first movers don't always win, but you get the mind show.
And that's a very valuable thing.
Exactly.
So how do you think about the intersection of like...
The things that a developer advocate might do with more traditionally engineering or product world, especially because now there's so much new everywhere on the education front, but also in the product engineering world.
How do you partner internally as well as part of your role?
What's cool is that I now have a lot of leverage to do engineering work because of coding agents.
So I'm able to ship.
more complicated demos than otherwise I would have been able to build.
I'm able to ship programmatic SEO on top of just ordinary sort of blog content.
I'm able to write custom software to make the process of creating and publishing a book easier.
There's a lot of different things I can do on the engineering side.
But at the same time, I don't really think of my role as a developer advocate in terms of creating alpha and a lot more around distributing it, discovering it within the company and bringing it to the market.
And with that, that takes the close partnership with engineering to know who everyone is on the engineering team.
a big challenge actually now because we're going through so much hyper growth.
Got to know who everyone is, know what they're working on, know their communication style, what they're going to be excited to talk about.
Some people are very loud when they come up with a breakthrough.
Some people just kind of ship it as a PR and don't talk about it.
And so you have to be able to surface all of these different styles from across the organization and say like, all right, of every awesome thing that got shipped this week, like what is going to make the biggest impact?
The other piece is helping enable the engineers themselves to become content people because a piece of content or an idea is always going to be best received coming as directly from the source as possible.
So if that's ghostwriting, if that's co-speaking, if that's just like getting people a Twitter account and saying, go have fun, there's a lot that you can do to...
turn your army of engineers into an army of content people in a way that helps your company's brand be very authentic and very technically driven.
Yeah, absolutely.
I mean, engineers are classically very allergic to marketing.
And the more that you can meet them on their level and also to empower engineers to tell their own story instead of telling it on their behalf, then the more flow of information that we have around all of these kinds of new ideas.
And it makes everything that we do higher leverage as well.
Yeah, I found that my engineering team is not allergic to marketing, in fact.
I mean, I think of myself as an engineer.
I'm an engineer by training, and I love attention.
It's all I do.
Relatable.
And so I guess that's why I say classically engineers are allergic to marketing.
I do feel like that perception is changing.
But the thing is like a lot of it comes down to just helping them understand the value of what they're doing on the go-to-market side.
Showing.
You know, engineers love numbers.
Like, I love seeing numbers go up.
So just you can sort of show impact that way, but also showing in terms of, hey, we were able to bring in this customer because of your work, or we were able to bring in these candidates to join your team because they saw the interesting work you're doing and they wanted to come work with you.
Just being able to demonstrate an actual outcome, a really concrete and tangible one, I think goes a really long way to getting just about any engineer.
hyped about the idea of of creating content i even i work with people who don't even want to you know get up on stage don't like attention at all and once they understand like okay you know if i do this i'm going to get recruiting i'm going to get customers then then they're willing to to get up there and and get a little spotlight on themselves yeah exactly and i i think as well like you made a good point about how they don't Typically, maybe get as much exposure to the customer and their problems.
And so once they get a taste of that, it becomes really exciting to be engineering and delivering things where it's like then you go meet with the customer or able to get closer to like how somebody used something that you shipped.
Because at the end of the day, we all became engineers because we wanted to build cool stuff that people used and it gave them value.
And so I think the closer that we all get to the reality of that conversation.
the more productive and the happier and more fulfilling our jobs even feel, which is what you kind of called out there, you know, about like one's engineers kind of start to figure it out.
And I like how you said, too, about distributing, like the distributing, like the alpha distributing the gains.
You're more like a bridge.
I think that's classically like really when the developer advocate role has always traditionally kind of been like this.
Marketing to product bridge or marketing to engineering bridge.
And now it's a bridge between a lot of different places.
And frankly, I actually think that's really a fundamental trait of the new AI leadership kinds of roles that are popping up.
at companies is that they're ultimately brought in to be a bridge because rolling out AI across a company is a very cross team, cross department initiative.
You need somebody who can meet a lot of different problems at a lot of different levels and inspire people to come together to work on that.
And so like, you know, at Dev Interrupted and at our parent company, Linear B, we talk a lot with folks that are in a developer of AI enablement role.
That's somebody who's tasked with making AI a reality specific.
for the engineering team.
So they can use it and they can ship with it and deliver it safely and the company can understand the impact of that.
So understanding the impact of how we're adopting this new technology is really important for a lot of companies.
How do you think about measuring or understanding the enablement of the work that you do?
One sort of difference is that my work is much more externally facing.
That said, I do a lot of internal enablement as well, especially within the go-to-market team.
What I like to measure is almost like a language learning process where the first step is trying to get people conversational, understanding the nouns and the verbs and how all these concepts work together.
And then eventually we want to get them fluent where we feel really good about putting a seller on the phone with a technical point of contact at a customer.
and having them be able to go through a discovery process and go through a genuinely consultative cell without every time they hear a word like VLLM having to run back to the engineering team and ask what's going on.
And then the ultimate goal is to sort of become AI native in whatever role they're doing.
So like an AI native seller who really understands the space and has a strong intuition for what individual customers need, you know, an AI native engineer who is able to seamlessly use these tools to accelerate their work.
One thing that we've done, which is really exciting, is we have a, from our infrastructure team, a mechanism for deploying Vibe-coded sites in a sort of secure, centralized, and standardized way.
You know, it's behind our single sign-in gates.
It's limited to only base 10 people.
And with this, I've been able to ship cool sites, but also people from outside of engineering teams, from our people team, from our sales team, from our operations team, have been able to create custom tools and then host them internally through this sort of centralized mechanism.
This is the sort of tooling that I think is really effective for these kinds of...
enablement pieces because if you have everyone just kind of doing their own thing it can really spiral out of control very quickly but you also don't want everyone to have to go through a big you know procurement cycle every time they want to just like ship a little web app so having a a strong strong set of tooling technical tooling in place to be able to just like let people ship is i think one of the biggest unlocks you can have for delivering ai across the organization yeah i couldn't agree with that more we've we've talked about that a lot on the show from leaders who are working on or building in spaces or otherwise have adopted these kind of closed ecosystems within not just their engineering work, but their whole company where anybody can go to this one platform and make an app or make an agent or deploy or share a workflow.
And it's one about centralizing and standardizing all of them in one place where they can be controlled together.
But then it's also too about sharing your domain expertise, getting other people involved in what you're working on and building.
Finding unexpected users and use cases of things that you're building and by having a centralized place where all of that comes together, I completely agree, is really critical.
We had James Everingham, the CEO of Guild AI, and he talked extensively about how he had built exactly that when I think he was at Meta.
And so when he was at Meta, he had built a platform where folks could build and ship like internal apps and agents and tools.
And the adoption off of that was, you know, it was it skyrocketed and it got the whole company to become AI enabled in a really structured way.
I'm curious to speaking about the whole company.
How do you think about like making it so that.
We talk a lot about the show about the broadening of skills and the rise of the generalist.
And you get these deep specializers and you get these broad generalists, like a designer who can ship or an engineer who can go to those customer meetings.
I'm curious how you think about the shape of skills that engineers are developing and what's most important now.
I think that what I'm seeing a lot is people with too deep skills.
If we've previously talked about T-shaped engineers, maybe this is an upside-down U or something.
I need to brush up on my alphabet shapes.
It's a double T.
A double T, yeah.
Generally, for me, it's engineering and writing.
Engineering and content creation in general, speaking, all that kind of stuff.
For a lot of our engineers, it is that customer-facing...
communication and accountability piece.
One thing that we do is we have a forward deployed engineering team.
This team reports up to our head of engineering.
So at a lot of companies, you have a sort of sales architect, sales engineer motion where these roles are sort of within the go-to-market team.
And at the moment, we don't have something like that.
We have highly technical sellers.
who are able to go out and sort of speak to the customer and understand their problem.
And then we have a team of four deployed engineers who, again, sit within the engineering org, are in the Slack channels with the customers, are deploying into customer accounts, are doing sort of hands-on development, co-engineering with the customers, helping them figure out what model is going to be best and figure out which parameters are going to result in the fastest inference.
Because of that forward-deployed engineering function, and especially I think because that function exists within the engineering org, there is a culture throughout the entire engineering org of being customer-facing where it's very common for engineers from other teams, like infrastructure and model performance and core product, to go directly to the customer.
ask them questions, get feedback on the product, help them get unblocked on tricky issues, and then take that feedback and work it into the product.
So I think that's the first sort of big second skill for a lot of engineers is being great at both the building piece and the sort of one-on-one customer interaction, which especially when you're working with highly technical customers can definitely be a lot more comfortable than say like, speaking on stage or doing a podcast, writing a tweet thread.
The other way to look at potentially a two parts of depth, two legs of depth would be to say, okay, so you need to be an expert in AI technologies and the models and the harnesses and their capabilities, and in one piece of traditional software engineering.
So it's AI and CUDA kernel optimization, AI and keeping the Kubernetes cluster alive, you know, AI and billing infrastructure.
There's got to be some additional depth beyond just the AI stack in order to sort of match that domain expertise with the acceleration of the tools rather than just kind of everyone being a slop cannon.
Everyone being a slop can.
It's like obviously about doubling down on your specializations.
Like if content or something else is not your particular strategy, that doesn't have to be part of your double T strategy.
And I also like to how you, you cut off the importance of like the, before you get into the T's, when you're talking about the generalists stretching across, the importance of like really.
Creating that solid highway across your whole organization so that those generalists that that designer can ship can really easily go through the pathways to do it.
That's like actually key because it's like just because you have the skill doesn't mean you have the organizational throughput to execute on it.
They're like those are two different.
Also, too, like when you're picking your specialization, I like how you called out like it's usually like AI and something else, AI and this, AI and that.
It's oftentimes these folks who are deep domain experts in something in a pre-existing way or have accumulated that knowledge really quickly through working with other tools or methods.
And then they pair that with obviously the ability to be agentic and to distribute those gains to other people.
I think like that's really the key.
unlock is being able to then distribute, like you said, the gains, which is what then AI is enabling them to do.
I'm curious from my own personal perspective, because, you know, you wrote a book, Inference Engineering, and it's during a time when the industry is changing so, so.
Much like here on Dev Interrupted, we have a hard time even keeping our news segments fresh from week to week from when we record them and then when we publish them because the space moves so fast.
So I want to learn more about like how you went into writing inference engineering, what folks can learn from it and how you how you went to set out to write a book during an era where like, you know, everything is changing so rapidly.
You know, in marketing, we have an idea of like evergreen content and, you know.
Publishing something on trees is definitely putting your flag in the ground and saying, hey, this is going to be some evergreen content.
I was in a big rush to get this thing written and published because I felt like, okay, maybe this is going to have a 12 to 18 month shelf life from when I put it out.
I've seen a few changes.
Obviously, you know.
My book talks about DeepSeek 3 when we're now on DeepSeek 4.
It talks about Kimi 2.5 instead of 2.7.
There's, you know, things here and there that are updating.
You know, my section on quantization doesn't have anything on polar quant.
There's, of course, progress in this industry.
But I've been working at Base 10 on inference for more than four years now.
And I've seen, you know, especially over the last year, the stack become a little bit more solid.
You know, the foundation is there in terms of, you know, CUDA through PyTorch, through your various options for inference engines like VLM, SGLang, TensorRT, LLM, Dynamo, and some of the orchestration stuff on top of that.
We're seeing, you know, some standardization in the cloud providers and in the NeoClouds and sort of the way that they present GPU compute.
the way that compute can be purchased, allocated, scheduled, controlled, spun up and down.
So while there is a lot of change in this industry, we're getting to the point where many of the fundamentals are becoming settled, at least when it comes to inference.
I think that training, the training stack is a little bit less settled right now.
The sort of agent orchestration stack or the harness stack is very, very up in the air.
There's still a lot of...
questions about what that's going to look like long term maybe that's kind of more like the javascript framework of the ai industry where there's just kind of like a new framework every every couple months that people are switching to and and eventually you're sort of like angulars and views and reacts of of the industry sort of come out of it but for inference particularly there is a good deal of solidity in in the fundamentals of this space and i think that There's a lot of opportunity, though, still to sort of push the envelope on inference.
Like, when we publish blog posts, we're talking about being 20 or 40% faster, like 2 or 4x faster.
Like, if all the low-hanging fruit was gone, we'd be talking about our 2% and our 4% optimizations.
That suggests to me that we need a lot more people working in this space.
And so if you can make the fundamentals sort of broadly accessible and easy to learn all in one place, then like engineers can come into this space.
And I've seen people get up to speed in like weeks to months and start making sort of frontier contributions in inference.
Because, again, while like the fundamentals are pretty settled, there is a ton of work to do in the sort of optimization and the last mile delivery of inference to the vertical AI companies, to the new labs who are making their own custom models and to sort of the world of developers at large in the form of like faster, cheaper, better tokens.
Yes, you made two strategic bets.
And going back to the original idea at the beginning of planting the seed, of getting it in the hands of folks.
That way they can learn and they can have access to the information.
And the second thing is, you know, you bet on primitives.
Like what you said, there's some core underlying parts of it that are solid that you can talk about that aren't going to be rapidly shifting without otherwise changing the entire definition of the space anyways.
In which case, having to go through and update the Kimi 2.5, the 2.7.
is just a custodial task compared to that.
So you captured the primitives and made them accessible more broadly.
You broke them down into a language that wasn't going to immediately get outdated.
Going back to your thesis around it being evergreen and fighting to make it last as long as possible once it left your hands.
I want to learn a little bit more too from you about how within the book.
how you think about equipping folks to work with inference as traditional software engineers, as people coming from other fields.
What are some of the things, now we're kind of getting into maybe the content of the book a little bit.
What's your biggest takeaway that you really want engineers who pick it up and open it to really be able to extract it and run with?
My thinking on the book is that any given engineer with a bit of experience who picks it up is probably going to know one or two chapters better than I do.
If someone's an SRE, and they read chapter 7 about production, they're going to be like, well, what is this?
Inference for babies?
You know, if someone is an ML researcher and they read chapter 2 about the architecture of these models, they'll be like, yeah, bro, I get it.
It's matrices, and you multiply them together.
Like, we've been doing this for a decade.
What's up?
I think that the interesting part of inference is the absolute breadth of the stack, where you have to go from...
reasoning about the architecture of a set of neural networks, to thinking about the specs of your GPU, to thinking about an entire stack of technologies from CUDA to PyTorch to an inference engine, to a bunch of new research optimizations that you're applying in each of these technologies, to modifying that depending on your modality and then shipping that on scalable infrastructure.
There's distributed systems problems here.
There's sort of competitive coding style algorithm optimization problems here.
There's business and economics problems here.
There's just a lot to think about.
And so my goal with the book was to take one of those engineers who has the deep expertise in one part of the stack and expose them to the ideas of everything else that's going on and how all these pieces fit together.
Because ultimately, there is no one silver bullet for inference.
You can't just get some GPUs, take an inference engine, slap the two together, and be like, boom, tokens, and expect that to scale and to hit frontier performance, to hit three or four nines of uptime.
So yeah, that's kind of the goal here, is to deliver the message that inference is a stack, it's a complex problem, it's not just one thing.
And so it's like the surface area, like you're saying.
It's very broad.
There's a lot generally broadly that you can teach and you can share and that you need to.
And you're going in writing a book where, you know, people that are reading it are going to be an expert on you and some of these really broad domains because it's impossible to be a better expert at somebody in all of them and to capture that.
And, you know, that's really a really kind of like.
As a writer, that's like a sensitive and a hard place to put yourself into, but it's also really bold.
And it's kind of like the direction that I think a lot of folks need to do in sharing their expertise and their content is about betting on the primitives or presenting it in a way that makes it as broadly accessible for people within the same problem space.
But then also to just really equipping them with the mindset reset that they need.
I think we talked about that week after week within our show about how a lot of time is within engineering right now.
Your biggest obstacle is your assumptions from yesterday.
not the technology you're holding in your hands.
And being able to understand what is holding me back and what do I need to invent net new are two totally different questions to be asking.
And folks are typically asking only the order why you need net new.
And so it's about revisiting all of those fundamental disciplines and principles and going up to them and shaking that SRE on the arm and being like, you know, like.
I know you know this better than me, but there are some parts of this that are a little fresh that are still going to probably be helpful for you to be reading.
You know, just kind of like tying this back maybe a little bit more to base 10 as well.
We talked about how your role is educating folks within the space and about making AI more broadly accessible.
And that's all part of base 10's mission of providing an inference platform.
I'm curious, like, what is it like working for a company that is working within like the inference platform space that's such like an on the edge kind of domain?
What are some unique things that you see or that you all work on as a business that might be really insightful to our audience who's more coming from a traditional engineering org that's making a transformation instead of being a more AI-centered one?
I think that one thing I've learned is everyone thinks about influence and the problem of influence differently.
One thing that's been pretty cool is actually hearing from developers at companies like NVIDIA.
OpenAI and Google Gemini who are on influence teams reading and debating and engaging with this book.
And I'm like, guys, why are you reading this?
You're already experts on this topic.
But what they tell me is, well, yeah, we know how we do it, but we want to see how everyone else is thinking about it too.
We want to get those outside perspectives.
I've been very fortunate to see the perspective of hundreds of different companies in terms of the way that they think about inference.
And one thing that we're increasingly seeing is this idea of an AI native company where inference is mission critical.
What mission critical means is that it's in the revenue path.
If your model goes down, your product goes down, you're not making money, your users are churning, they're going over to something else.
And that's a very different thing than a lot of companies maybe earlier in that transformation are seeing where AI products are just kind of a bolt-on to their existing platform rather than the actual foundation of the thing that they're building.
I think that when companies make that transition from the add-on to the foundation, they start to experience a ton of pain.
Like, wait, why is it so expensive now that I'm doing tokens for thousands or millions of people instead of tokens for a small group of beta users?
And why is my app crashing and slow all the time?
Because I'm sitting on top of some public model API that's got like one or two nines of uptime.
Or why is everything routing through the very smartest and most expensive model in the world when a lot of my users are doing very, very basic tasks?
So the things that work in this space at the pilot scale and at the early scaling place.
do not necessarily work when you're rolling out an AI platform to an entire company of tens of thousands of developers or to a user base that is, you know, America or the world.
It's exciting to go in and solve a lot of these challenges, especially around latency, cost, and reliability, because those are challenges that engineers have been working on for decades.
And every new technology brings a new round of questions there.
And in this case, we actually do have a lot of tools to address these challenges.
And it's really exciting to see these technologies hitting a scale and a sort of penetration throughout the market much faster.
at a much greater scale than many previous generations of technology, you know, two or three years into their rollout.
Really well said for like mobile or like PC, internet, like any of these previous things were not this deeply penetrated into the market like three years in.
Yes, which is what's going to be quite crazy about the transformation I think is still ahead of us.
And I really loved how you called out the difference between adoption and scale, there's a really sea change in terms of your practices and how you actually do implement and roll it out.
And it makes a really great case for once it becomes mission critical about having the support and the need of the entire infrastructure, the entire platform behind it.
And that's what Base 10 is providing in this case.
And actually, it's funny, very recently on one of my news segments here with my co-host, Ben, we were just talking about the model.
router problem about how that's still kind of like people haven't really it hasn't clicked with a lot of folks but also too you see a lot of ships products or people that are using a tool and you're using an opus call to do something that could just be like a haiku inference call, right?
There's like levels of optimization and understanding which queries go to what level of intelligence model that I think a lot of folks are still really early on in understanding, which has massive implications for scale.
So that was a really timely thing that you mentioned there, something that we just recently talked about on the show.
I love that.
Yeah, I mean, everyone has an AI pilot, but certain organizations are really sort of accelerating into the curve here.
And others are not.
And it's interesting to see, like, who's kind of there and who isn't.
Exactly.
Well, you know, we're coming at the end of our chat here, Philip.
And I want to thank you again so much for joining me here today.
Where can folks go to learn more about you and check out your new book, Inference Engineering, which we talked about today, as well as Base 10?
You know, where can they go?
Yeah, so I try and make my stuff pretty easy to find.
If you just Google Philip Carley, you Google Influence Engineering, you're going to get there.
The actual link is base10.com slash influenceengineering.
That's going to get you a place where you can download a free PDF, free EPUB of the book, or pick up a paper copy, which I try and do more or less at cost.
I'm not making any money on this.
You can also find me on Twitter and LinkedIn at fellow Kylie.
Very consistent in my branding there.
And yeah, I'll be at AI Engineer World's Fair coming up here in a couple months.
I try and really hit the conference circuit, hit the meetup circuit here in SF.
So if you're out here, come say hi and let's talk about inference.
Amazing.
Well, I'll say hi next time I'm up there as well.
To those listening, you know, definitely be sure to go check out the links.
We're going to share them in the show notes as well.
And if you're not already following Dev Interrupted, wherever you're listening to us, definitely be sure to...
to do so.
And make sure you're checking out our newsletter that drops on LinkedIn and Substack, where you can find follow-up links and discussions as well as some of the news topics from late.
As well, I would love to connect with any of you all on LinkedIn.
So please reach out to Philip or I and continue the conversation.
We're going to be posting about this once it drops.
So Philip, thanks again for coming on the show.
We're definitely going to be chatting with you more in the future and continuing to follow all of the stuff that you do at Base 10.
So thanks again.
Awesome.
Thank you so much for having me.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the APEX framework comes in.
APEX is a new operating model for engineering productivity, designed to measure AI where it actually matters, at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
APEX is built on four pillars, with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.