# AI Cloud Strategy and Engineering Productivity

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

## Transcript

You're listening to Dev Interrupted by Linear B.
This week, we're taking a field trip all the way down to the GPU.
My guest is Dan Fu, VP of Kernels at Together AI and an assistant professor at UC San Diego.
Dan runs a research lab where he co-authored the Flash Attention paper, and he manages an engineering team at the same time.
We talk about how ideas cross between them, what it means to build a cloud for AI.
and how to split up the work when AI makes your best engineers even faster.
Ultimately, Dan sees AI as an accelerant for individual engineers.
And at Linear B, we work with teams on what comes next at an engineering level as well, turning those individual gains into team outcomes.
So let's get into it in our conversation today with Dan.
If you've run a model in the last few years, you've almost certainly touched Dan's work in some way.
And what I find the most interesting about Dan is he wears a lot of hats.
runs a research lab, he's a professor, leads an engineering team.
So today we're going to talk about what happens when research and engineering stop being separate departments, start becoming a harmonious loop, and what it means to build a cloud that's designed for AI from the start.
So Dan, welcome to the show.
Thanks so much for having me.
It's really fun to be here and looking forward to a great conversation.
Amazing.
Well, we're super excited to host you.
And, you know, I really got to start with the part.
of your very unique kind of assemblance of roles and responsibilities that you do.
I think that really gives you a unique perspective.
I want to frame from this part.
Could you tell me a little bit about like your background and being like a professor and being in a research lab as leisure capacity as VP?
Yeah.
Yeah.
So like you said, I wear a few hats.
At Together, our team runs the whole inference stack, you can imagine, as soon as a request enters data center all the way down to the GPU and everything in between.
So we think a lot about how to get more tokens out of the same hardware so that when you're trying to use it for coding or chat or, you know, chat GPT, tell me what plant this is or whatever.
all that stuff.
We want to make it so that all those capabilities are available to a lot of folks.
Separately, I run a lab at UCSD.
And there I have a few great students who are doing all sorts of research on, you can think of it as next generation architectures and things like that.
So yeah, it's a lot of fun, a fun intersection of the research and the engineering cultures.
And did Juan come first?
Or did one comp lead to the other or did they emerge at the same time?
Let's see.
So I've been at Together for about four years now.
Started part-time during my PhD.
Near the end of my PhD, went on the faculty job market and got the position at UCSD and started running a small lab there.
So I guess they kind of rose in parallel with each other, which has been fun.
No, I've definitely, I've been meeting folks like yourself that are like dually armed going down this like academia path and this like applied engineering applied, like in the industry path.
And I think actually there's a lot of opportunities now to bring that kind of work, which traditionally has been so bridged closer together in terms of just accelerating each other, building off of each other's progress.
And so.
Like, what does it look like, I guess, then bringing that kind of mindset into your role at Together?
How does your ideas around those things like then impact the actual engineering that y'all end up delivering?
Yeah, yeah.
The way I think about it is the ideas, the research ideas that are a little bit more out there that could work one day that could have the moonshots.
Exactly.
but that won't necessarily translate to something immediately.
Those are the ideas that I tend to explore more at the lab.
So the funny thing is, it's actually a lot quicker of a loop than it was even when I was doing my PhD.
So one set of ideas that one of my students has been looking to at UCSD is this idea called looped models, where you take, so traditionally you think of a model as you have some input.
goes through all these layers of the deep learning transformer.
A basic idea of a looped model is instead of just going one after another, some way in the middle, you're going to go back and do this big loop.
And he was really interested in this idea, found that it could add another axis of scaling.
You can get the same performance with a lot smaller model, stuff like that.
And, you know, in my mind, I'm like, OK, this is a this is a cute idea.
It's really interesting.
Maybe someday somewhere in a few years, someone will scale it up.
But then I think some news piece like the information leaks that GPT-6 Astra might be a looped model.
So I'm like, OK, you know, the the the the time from cute research idea in the lab to someone reads it and goes and implements it in an industry at the.
in the biggest, the biggest cases seems to be a lot narrower than it was before.
You know, the line is kind of blurring.
But yeah, it's very, I think that the ideas that for me are just driven by pure interest happen in the lab and then together with that team, it's a lot more driven by there's some big open source model.
How do we make that one in particular more efficient?
Totally.
It changes the math on like the traditional kind of R&D idea and like what you're saying about like you bring the idea to the lab where it's like really early in its infancy or it's not relevant in the pathway of a media application yet, but you can bet or you can foresee, you can hypothesize that if.
will be and it will take X amount of time to figure it out.
And if we figure it out now that we won't have this bottleneck later.
So like that's an evaluation you're constantly making in the lab of like, what do we pick up?
What's going to unblock us?
Like, because really what's happening, especially in engineering, like teams are working so quickly producing so much more code the cognitive load of what they're like putting out day to day is is so massive that they usually can't even get a grasp on it and this then causes a whole bunch of bottlenecks right like you have the review bottlenecks where like code review is just turned into a big ceremony no one reads it anymore You have an ownership issue with the code and who wrote it?
Oh, an agent wrote it, but who prompted the agent?
Where did that agent come from?
What is it building on?
So all of these problems, there's so many of them.
And so teams kind of get like scattershot about like, what do we attack?
And what do we solve?
And by having a lab, you can be more strategic about like, this is our menu of problems.
And these are the pain points that we need to apply deep.
thinking and not only thinking, but we literally need time.
The access of time is not scaling at the access of capability from the model.
So we literally need time to bake these ideas.
I can't make time, you know, I can't make more time.
And so, and so it really becomes like symbiotic between the two, the research and the, and the lab.
Yeah.
Yeah, I agree.
Yeah.
I think the, the real thing that differentiates the lab research is that it has to be really driven by, by personal.
by personal interest and student interest.
It's like, I always tell my students, like, if you pitch me an idea and you tell me why it's useful, I'm like, maybe not.
But if you tell me why you're interested in it, then that's something that you want to go spend a lot of time on.
So it's a very different value function and selection function there.
And you call out how it becomes a quality in a person.
Like, I was at a talk.
It was a...
There's a conversation hosted by Jorkesh and Dr.
Fei-Fei Lee and it was in WorkOS was hosting it.
It was really cool.
And something that she said she admired in her students, in her lab is intellectual fearlessness of just being completely fearless about being curious about something and not giving up on that curiosity and not getting discouraged along the way.
And that for her, like when she had a student that had that pairing of.
that intellectual fearlessness and they came to her framing it exactly how you did like i i'm really curious about this i want to know about this i think this is important it transforms like the whole research process and the timelines like you said become so compressed where you're like actually now this once upon a time moonshot could be a realistic thing you shoot for and how does that how does that impact like how you even think about like hiring and skills you look for both like in the lab, but really, I guess, moving to like thinking of applying this into the engineering route where a lot of our listeners, that's where they, that's where they work every day.
And they're wondering how to apply this kind of thought.
Like, how do you, how do you bring that into bringing in really good engineers?
Yeah.
Yeah.
I'll, I'll, I'll just the lab piece quickly.
I think when I'm, when I'm looking for folks for the lab, I think that that phrase intellectual fearlessness is, is really a good one.
So.
there's you know in the history of research there's countless ideas that um started with you know oh i had this idea but my advisor said no um and or like i had this idea but someone somewhere who should have known better better than me discouraged me um but the the really great thing about a phd is that that you have the time to to explore that and you have the time to to go down all those paths that that may not make it so no one told you can't go down the path that's what the exactly exactly yes yes yeah yeah um it's it's almost the the naivete of like uh you know nobody told me that this thing was impossible until until i did it until i did it yeah exactly exactly um so yeah that that that that's certainly one quality i look for in the lab um when i'm building the team that together uh i think it's it's a uh you know that intellectual curiosity is also some something that i look for but um a lot more of it is kind of um who's willing to get down and dirty with the details so The systems type of work is very much, you know, I think one thing that those of us who spend a lot of time in it is that you can actually go and understand all the details.
You can actually go all the way down to the hardware and understand what every single little thing is doing.
There's this part of AI machine learning research that's kind of the models are too big.
There's too many parameters.
uh it's like during doing neuroscience or something to try to understand why the model said a or b um but when you're just optimizing the the the runtime of a model or optimizing a attention module or kernel or something like that uh it's also very complex there's a lot of moving parts of course but you actually can go down and say this is what's happening on the gpu all the little pieces and oftentimes you need to go and look under all those stones to really understand what's happening Um, so that, that is the quality that I select for more in the engineering side, just that, um, leave no stone unturned type of thing.
Um, and then of course, I think if you, you have to enjoy the, the, the deep, the system, the deep system, the person you're describing.
is turning over every single stone.
We're operating in a very tight, safe kind of reality.
And so it's really kind of funny to see how the shape of the kind of tooling that you work on really impact the actual skill sets that you need for very specific kinds of engineering, especially when you get so close to the hardware.
Because there's many engineering leaders right now who would argue that the engineer they're looking for has this...
fusion of like product craft and understanding the customer need and talking with them.
But it also still speaks to like the deep engineering work that's still required to scale all of that opportunity, which is what y'all focus on at Together.
It's kind of the idea of being in like the cloud category right now.
And you see a lot of folks call it like the Neo cloud because it's really about a mindset shift, a reset about how we think about.
those resources and scaling them.
And since we're accessing them and leveraging them in new ways, now suddenly we have to do deep research to understand how do we get every little bit out at the scale that we're going.
Exactly.
Yeah, I think.
How do you think about that?
How do you think about navigating that world in the cloud world now?
Yeah, it's it's very I think the type of work that we do is very deeply technical.
And it is the type of thing that I think, you know, when you talk about the engineers who have that product sense, certainly like we look for that.
We love having folks who can talk to customers and understand those bottlenecks.
Once you do that, it ends up boiling down to two or three numbers that you have to actually go and make the thing like get more like it's going to boil down to cost or like some quality or something.
some TPS.
And then once you understand that and what's happening on the other side, which is if you do it right, it's one or two calls, then you have the rest of your week, the rest of the month to actually go and hit those challenging technical goals.
I think it's interesting.
So we've certainly started using AI a lot to accelerate our workload.
So we can write kernels way faster than we were able to a year ago.
We were able to build entire parts of the inference stack a lot faster than we were able to a year ago.
But one thing that is definitely, I think, more true now than it was before is that the more domain expertise you have in something, the faster the AI tooling lets you go.
So if you are coming to it and you don't have a really strong understanding what's happening on the hardware, what's happening in this complex software stack.
The AI will let you write a lot of code, but it might not be the right code.
It might not have the right design.
It might not be doing the right, might not even be correct because of some ABC different edge cases.
So when you're in that position, I think what we found is that the more domain expertise you have, the more you deeply understand something, the more effective you are, the faster you can go.
Yeah, absolutely.
It speaks to AI as the amplifier in this case.
Like if you don't have those skill sets, if you don't have that curiosity, if you don't have that, you know, you can lack the domain expertise.
But if you also lack the reflective skills with an agent to build that expertise and the pathways of building that expertise like outside of a chat, right, then you kind of starve in terms of being able to like leverage that for decisions.
for people who are working on like deep system stuff, there's a lot of partnership still between agents and humans that get stuff across the finish line, especially because it all comes from a realm of innovation, which agents have spiky, you know, things within, but still ultimately like requires a bit of a spark that can be hard just like to expect to appear in a loop somewhere.
And another thing too that I've noticed is that like, AI enablement came for everyone unequally.
And like for people that were in the product world, the SaaS world, the customer facing world, writing the reacts and the front ends of like their ecosystems and their industry and their, the tooling they used every day evolved so rapidly and so quickly over and over again.
And just like fundamentally the way that they were able to leverage the tools were fundamentally different.
Meanwhile, you folks that were on a lot of like, uh, embedded language, like embedded systems and like deep languages and, and, and, and things that did not have as much code in the training data that all these foundation model trained on that did not have those same experiences.
And so they would use those same tools and get like crappy results, or they would not get anything near what their peers are talking about.
And then you get like a, a distaste, you get a divide.
So, you know, I think it's always been about like within that realm.
where if you've been like shunned away by AI because it was really crappy at your domain, having like the persistence of pushing it and being like, why is it bad at my domain?
What can I give it?
What's the scaffolding I need to do?
I imagine that like, y'all just ended up building this like, you know, probably a wild looking factory in terms of how you push the research along between each other as researchers, but then also across the line into like the engineers.
How do you think about systematizing it as a systems thinker?
Yeah, I think it's really interesting.
So, I mean, first of all, the AI ability to generate really fast front-end apps and things like that.
So half of understanding what's happening in these systems is building the right visualizations, understanding the data deeply in doing that.
So even before AI was able to write kernels at all, the ability to build those visualizations was hugely impactful for folks.
um acceleration so we we built our own like perfetto viewers our own trace viewers um our own tools for tracking uh how fast the the engine is going how much how much data it's processing how many tokens you made windows you made windows like you had this like big black box where all this stuff was happening you you punched some windows into it you created exactly exactly share and talk about it yeah Yeah, yeah, yeah.
I thought you were talking about Windows, the operating system.
No, no, no.
I mean, we didn't go that far.
No, you punched literal holes in the wall of the black box.
And you said we have the opportunity to not only go really fast inside this black box, but wouldn't it be cool if we leveraged some of that to visualize and to share language on like what is happening?
And I imagine this kind of helps kind of tackle bottlenecks too.
Exactly, yeah.
So that ability to, it gives you a new microscope almost to go in and look at what's happening and understand what's happening.
That tooling was hugely impactful.
The AI models, the coding models still kept improving to the point where I think a year ago they were able to write some kernels, but not a ton.
Now they can write a lot of simple kernels.
And if you equip a strong kernel engineer with a good coding model, you can...
generate a lot of kernel.
Sorry.
And for the viewers who don't know, so kernel just means GPU program.
It's like, it's a fancy word for GPU program.
I don't know why there's a different word for it.
But it just has to be special.
It's just a little building.
It's just a little building block of leveraging the literal GPU hardware to bridge into the realm that we're trying to all build on top of.
Exactly.
Which is why that's like in conversations like this.
you know, you're not even like the first like kernel researcher that we've talked to on the show.
Like ultimately so much as a boils down to this level because this is about as fundamental as you get before you start just moving into like raw power inputs and things.
And so it becomes where the problem has like the highest opportunity for folks that like really eke out a small advantage, that advantage scales all that way up.
And so that becomes like why the opportunity is so big.
And speaking of the opportunity being so big, you know, together is expanding.
Y'all have like are continuing to get more partnerships, your surface area of your platform, where people are training and running models gets bigger, gets more higher performance.
What are some of like the big bets that y'all are making in the future?
Like as you think about like defining the AI cloud category?
Yes, yeah.
So I think so the when when I think of the AI cloud, I think a couple there's a couple analogies I think of.
So first is, you know, what is the analogy to the old traditional digital cloud?
If you look at AWS, it's not just machines that are running CPUs.
It's the databases, it's the logging, it's all those other pieces to it.
And I think the AI cloud, we are building up similar sets of infrastructure as we grow.
So it's not just GPUs for training your models, but it's once you've trained the model.
So training is a one-time cost in some sense, but then...
The only time that anybody ever makes money in AI, the only time when you actually deliver value is at the inference part of it because that's when people actually use the thing.
That's the consumption endpoint.
Exactly.
So we're spending a lot of time thinking about inference, scaling inference.
We have partnerships with great model providers like Moonshot and Minimax and Cursor, who are, of course, spending a lot of time training really strong models.
And then we partner with them to serve inference.
So that's going to be a major strategic bet for going forward.
Where we're going and looking at how do you give training?
you know, expose training to more people.
So traditionally, the training side of the business, we've worked with very deep AI native companies where, you know, it's the AI PhDs who dropped out of their PhDs to go build a model company.
But there's a lot of folks who are just getting into it.
And especially as AI expands in the economy, there's a lot of other folks who are thinking.
How can I use this great new technology in my own business?
And you might need to customize it or post-train it or fine-tune it.
So we're thinking about those folks and how do you enable those folks to use these new capabilities that are being developed and how do you get them to work?
So those are a couple bets.
And we're just seeing the demand for AI.
grow in such such crazy ways so we're we're just um you know a lot of it is a supply game a compute game how do you get more compute how to get more supplies so that you can help produce more tokens for the world yeah absolutely i think the some of the biggest challenges i think are about Definitely taking this tooling, this infrastructure that used to be highly specialized for a very small subset of people or use cases.
And now we have we've totally cracked that open.
We've acknowledged that we're on this jagged frontier where even if we stopped innovating today on all things AI, there's still so much to go back and implement across every industry, all these work surfaces.
There's so much of that work to be to be done.
And we haven't even really started.
taking big bites out of it.
And so like, I think that's like going to be a huge opportunity.
And so that just then swells up where all of that is going to run, like what's going to support that, but also what's going to enable these companies, these people who now for the first time have to approach the, oh, we need a model that's a little specialized on this, or we need to figure out how to take this very specific.
combination of domain expertise and use it with a model to, to, and then serve it to our customers because our customers now, that's what they expect.
They don't want to come to my app.
They don't want to come to my website and log in and click around and look at dashboards.
They have their own dashboard world that they live in where all of their stuff flows in and they need to be able to, they need it on a consumer level, being able to plug into that.
And it's really interesting to start to see like, major players in like the market start to tackle the consumer grade AI agentic assistant kind of thing you have like muse which is making a big stir and everyone has a different opinion on it and and so I think that just represents like the very beginning of what's going to be like a vast amount of enablement yes almost more like we've joked about it on the show before kind of comparing it almost to like the eternal September of like AOL and Newsnet of like the idea that once AOL started sending out internet access emails to everybody in the mail and people got online for the first time, things like the user net boards were just expanded with people saying hello for the first time.
And that used to just be when college would start because those were the only people who had access to the internet were college people and students.
So like all of a sudden everyone, this whole whole world that college lived in is occupied by people that's why we that's why we exist and tolerate all the weird things about like the mail that we do because then all of consumer mail was built on top of the pre-existing mail structures and also um i think about like news groups and user groups and about how like that's been reflected into how we like communicate on the web and all of that comes out of like places like academia specialized computer researchers tinkering and building systems thinking about how this might scale, and then it's scaling explosively out of their control, and then all they can do is make changes and modify things over time.
That's kind of a parallel that I see that we're on a bit of a precipice with this kind of compute.
Yeah, there's a ton of interesting parallels there.
So my favorite one is, if you go back to some of the old papers from the 60s that kind of produced or proposed email for the first time, they didn't call it email.
But they kind of said, oh, you could have these two computers and they kept a network between them and you can send messages from one to the other.
You can have a list of messages that you read on the other side.
It can be just like sending letters over the old fashioned thing.
They even have the language.
At the very end of those papers, at the very end of some of those papers, there's a section that's like, you could also say, so, you know, since now these are all virtual, so you could send one piece of mail, send it to many people.
And that could be really interesting to communicate to a lot of people.
But you might get this thing where people get a lot of unwanted mail in their inboxes.
And it was like this paper from the 60s that was predicting spam email.
And it's like, yo, it's really interesting that you can go back and see some of those parallels.
Yeah, you can extrapolate then what happened against the reality.
Like, it's so funny to think like, obviously, you know, some PhD was thinking about, well, when you scale up this mail thing and you make it accessible, and then that hypothesis becomes an all too unfortunate reality that we're all just incredibly aware of.
I think that's like the fun thing about research right now is like, because this technology will be so widely transformative.
Those little like unassuming turn over the rock and find something interesting things could have really profound implications.
So being like, there's a lot of value right now of like being out there with the pickaxe and digging around and trying to find stuff and dig things out of the ground.
I've had a lot of like, I've really enjoyed working more on research papers, collaborating with like researchers.
I've done a lot of that.
in the last year, including even participating in a conference where I wrote a paper because it's just like, I think there's so much opportunity to like bridge stuff from the engineering world and all of like the things that we the tooling we use and share them more broadly.
And it just turned out that like there was a whole conference set up for people sharing the same kinds of ideas as me.
And that's kind of the opportunity I think that folks need to have now if like they're really curious.
Yeah, especially I think, especially in a, you know, when there's been an interesting thing going on, I think, in math academia where everybody got access to these really powerful models.
And suddenly these models could do proofs that were just that you're trying to work on for a while.
We haven't even talked about the math world.
They're having a total lockdown over there.
Yeah.
But yeah, I think there's something nice about sitting down and writing a paper yourself, though, because it gives you the opportunity to.
you know, really think about what you want to say and how you want to say it.
And what, like what, no, when you're talking about research paper, like you, you have some set of ideas, some perspective on the world, how do you, how do you test that out for yourself to see how true it is?
Or, or maybe there's there's something that you didn't quite understand.
And then how do you communicate that?
How do you present it in a form where people really get it and understand it.
And they care.
I think that's what makes a research paper really stand out is you read the beginning of it, you're understanding what they're going to explore, what the abstract is, and maybe the conclusion is solid, but I want the conclusion to really matter or to have some sort of resonant kind of thing, even if it's not a technical one, even if it's just like an implication of something to think about.
That's that that for me is what I would I always reach for.
It's like, what is the what's the what's the the reason in here that I would care about what this person learned in this paper?
Exactly.
Yeah, that that connection between like when you're writing, you're really trying to understand and really get to the to the root of your own thoughts.
And then like to spend a lot of time writing something and then to put it out there for people to read and consume and react to and and give you feedback on is, I think, you know, part of what makes this whole research thing so fun, part of, you know, being in this community.
And yeah, I'm glad that we still have that capacity, that capability to do it.
This episode is brought to you by Linear B, the engineering productivity platform.
Your agents now ship more code in a week than your team has hours to review.
And on November 18th, we go live with a walkthrough of Linear B's new agentic studio built to deliver outcomes when human attention can't keep up.
Co-founder Dan Lines opens with why we rebuilt Linear B around context.
Then the product's team shows it working.
I'm hosting with Jamie Burse, and we're saving the last 10 minutes for your questions.
So be sure to save your seat.
And if you can't make it live, register anyways, and we'll send you the recording and the assets afterwards.
Link is in the show notes.
So I want to take an opportunity to pivot just a little bit here and talk about more on the engineering application world of using and scaling AI, particularly on a team level, because this is really the nut we've been trying to crack on Dev Interrupted.
Maybe you can help us crack it.
And the problem is, is that as...
you start to get more agentic as a team.
You get pockets of maybe like one really agentic person or a really agentic team.
And you have team leads and your CTO, CFO asking like, you know, we're spending all of this money on AI.
We're trying to measure the impact, the outcomes of that.
There's clearly some agentic AI acceleration stuff going on, but how do we talk about it?
What's actually getting shipped?
Why does that actually matter?
All of these become like really big questions that traditional processes and engineering were built to solve, like code review and sprint planning.
And that kind of stuff kind of crumbles at the scale that gets unlocked by the way that we're a lot of teams are working now.
How have you all thought about?
building an engineering org, AI first, and preventing those bottlenecks from appearing?
How do you think about ownership with code as it moves through the SDLC?
These are kinds of questions that a lot of our listeners are grappling with.
Yeah, I think so.
Here, maybe I'll separate my answer into a couple parts.
I think there's a question in there about tracking cost, like how do you and how you do tribute.
We've been spending all this AI spend.
Is it actually accelerating us?
Is it actually making things better?
There's a portion there around, you know, ownership of different features or different ideas.
And then there's, I think, a little bit in there about.
how do you like the nuts and bolts of how do you make it easier for AI to accelerate your coding workflow.
So let me start, you know, addressing those one piece at a time.
So I think at the highest level, so going after the first one about that cost piece and the how do you attribute acceleration or non-acceleration to AI coding piece and AI spend.
How do you know if this thing was worth it when the CFO comes knocking?
I think for us, almost the traditional metrics of how do you evaluate people?
How do you evaluate, you know, like, how do you know if your engineer is good, right?
How do you know what they've been producing?
What, like, is it time for a promotion?
Is it time for a raise?
Do you need to have a conversation about their output and where they're spending their energy, I think.
And actually connecting back to the ownership piece, the world, that part of the world is still pretty similar.
So like, there's things that you need to get done.
You have to think deeply about how you split up the responsibilities.
You have to think about the organizational pieces of who controls or who's responsible for which parts of the stack.
All that thought, all that effort still needs to go into it.
Just because people have AI and we've heard people talk about AI agents, you're managing a team of AI agents and things like that.
If you're a manager or a manager of an organization or running an organization, you still have a responsibility to really think deeply about what your people are doing.
How do you help them grow?
How do you make sure that they have opportunities to show off their capabilities?
When somebody is ready for it, how do you know when to give them more responsibility for something that is key to the business?
I think all those pieces are still the same.
So the way that we do it, if there are key projects, if there are key features that need to be implemented, we still have...
people who are DRIs, we still have people who are responsible for it.
And the tracking, the management of that progress still looks very much like it did even before AI.
I think a major difference is just the velocity of how fast those things get done.
So, you know, we have to accelerate our planning, we have to change our timelines, we have to think about...
You know, how many people do we need and how much time do we need?
So those things change, but like your star players are still your star players.
It's usually clear to everybody in the organization who the star players are.
And you can see, like if you look at where they were now versus where they were six months ago or a year ago, if you've been following their progress over that time, you can see the improvement as the AI spend goes up.
And the flip side of that is, okay, at some point somebody takes a list and it's like, okay, here's the AI spend of everybody in the organization.
And then you go and you bring it to the managers who knows who's doing what and who's tracking kind of the impact.
The same way that you do it at a per review cycle.
And you're like, okay, this person, this amount of money, impact, super great.
Okay, thumbs up, thumbs up.
And most of the time it matches.
Occasionally you have a few people who's like, oh, wow, you spent that much money on AI.
And I don't know what you have to show for it.
Then you have to go and sort of have conversations with those people.
It's an increased leverage point.
So like if someone, you know, in some sense, you know, sometimes you may have underperformers who in the past would have just sat there and then at perf time, you're like, okay.
What did you do?
Let's try to figure out where you're spending your time.
Hopefully, if you're a good manager, you're having those conversations earlier because you're hopefully checking with your people more frequently.
I think there's a new failure mode of, okay, person who I thought was just kind of sitting around, maybe I need to have a conversation with them.
Oh, it turns out they spent this much money on AI spend.
So that's kind of a new failure mode.
I personally haven't really seen the one where it's like a really high performer that is also using too much AI spend.
Usually they're pretty calibrated.
Maybe it's because, you know, in our company, in our industry, like everybody kind of knows like what the spend correlates to on the other side.
But in many ways, it's still a classic engineering manager roles where you're like trying to help your people grow, trying to figure out.
what's the right way to split up work and responsibility.
So a lot of those pieces stay actually quite similar, both in terms of ownership and in terms of tracking the spend and attributing the spend to different, to pretty clear things that show up at the bottom line at the end.
I'm sure as you scale up much larger organizations, this becomes a much bigger fractal problem.
But I think even then, you know.
That was still the case if you were running a thousand person organization before.
You still had to answer to what are my thousand people doing.
Now it's thousand people plus the AI spend and hopefully failure core needed.
There was another piece in there about how do you actually make it easier for AI agents to operate under code and accelerate things.
I think there we've invested more time in kind of like Mark down agent read me's about what's going on so that an agent can pick up a piece of work and really start running with it.
And I think there's a new set of best engineering practices that is developing around coordinating, orchestrating, using agents.
Yeah.
I'm actually really quite intrigued that you used the word fractal in there to describe it because that is actually quite a really...
accurate way to describe what happens to the SCLC as folks get more and more agentic because, you know, earlier in the year we had like the whole Gastown transformation.
You had people starting to figure out like, how do I do this whole agentic engineering orchestration by myself at scale?
I have like 20 sub agents or in one orchestrator, like how do I build this?
And that person did experience a lot of.
gain.
We see this is visible like in our benchmarks at linear B.
You can see at the beginning of the year, the high AI usage, which was registered by just amount of their consumption usage compared to the lower users.
They just completely divided in their PR output and their lines of code output like more than 2x in some of those cases.
And so.
That was kind of like the transformation that happened for folks.
And when like the, the gas hound individual transformation came, it then started to call into question a lot of the, the parts of like what was traditional in the SDLC.
And one of them being like reviews, like you called out like a major, major features, stuff that is still like, has an owner.
Definitely.
I think most leaders on this show would agree with you.
Everyone says that these.
The PRs, even the ones that are agentically driven and created, they still have owners.
But then what happens is in this, going back to your fractal comparison, is that really what's happened is now the engineer themselves has become a mini SDLC because they have all these agents and they have all these repos and those processes.
And we're not really living in a world where it's like my gas town is going to call your gas town, like actually merging into Maine, getting nice and clean up there.
We're still figuring a lot of that out, which is, I think, really fascinating.
A big problem that we've seen pop up, too, is you get an uneven distribution in that review load.
So it does become important to pay attention to who cognitively owns, who's the DRI on the biggest bulk of agentic space.
And maybe they themselves aren't.
pushing and writing a lot.
Maybe they're not even agentically driving the creation of that code, but if they are the DRI, how big is that surface area getting?
Are they able to stay at the same mental pace?
These become the new challenges, which are totally, I think, foreign for a lot of folks on these teams.
So Fractal is definitely...
fascinating way to think about it.
Apply the challenges of API to solving the ones down low.
And I want to ask too, do you think about it in terms of a factory metaphor?
We see a lot of people talk about things like now as a software factory.
Is that kind of a language that you all apply internally or do you think about it differently?
Yeah, we haven't used factory, I think, as a metaphor before, I think.
It's not really assembly line type of work, I think.
I view it as an accelerant of individual people or individual engineers who are working on particular features.
And what I've seen is just that the capabilities of the 10X engineer become even greater.
Yeah, they turn to like a thousand X engineer.
Exactly.
We had Karthik Rankopal.
He's a distinguished engineer at LinkedIn Engineering.
He built over at LinkedIn their memory layer that enabled all of LinkedIn Engineering and LinkedIn in general to have a shared contextual layer with their AI agents really early.
So he identified this opportunity that was going to be a big leverage move for them.
He's very much like a lab scientist thinker like yourself.
And that was a real keystone to that conversation.
He was like, I don't want to be like the thousand X.
engineer.
I don't want to be that super agent.
I want everyone to be a 10 X person that they were yesterday.
You know, I want to distribute those gains because if you just end up with like the thousand X engineer, the thousand X engineer, what actually happens is they become black holes.
Like there's an event horizon around them where things enter and then you're not sure what the state of it is on the other side.
And so how do you distribute that enablement that like everybody is a challenge too for folks.
Right.
Yeah.
I think part of that becomes also on the engineering manager role where like I think the ideal engineering manager is spending time, of course, like there's people managing of like, where's everybody in their career?
How do they want to advance?
What are they thinking about?
But then there's also the technical side of things, like understanding what people have built, understanding what those features are.
and how you how you might want to think about the roadmap for that.
And I think that role become becomes very important.
Yeah.
Yeah.
It was already important before.
And I think it's still important.
It's even more.
Do you hear us listeners talk to each other engineers out there building things swivels here or less levels here?
Right.
Share what you're building, get folks involved in the process.
And we're moving so fast that just kind of helps to just kind of be constantly giving everybody.
And update and pulling them along for the ride as well, especially when, you know, the work that you do, especially, it allows so much to be leveraged.
There's a lot of curiosity, so much that we've explored in this conversation.
It's so evident about how passionate you are about what you work on.
And so it's been a real delight, Dan, to chat with you and to get inside your head about how you think applying the kernel world to the engineering one.
And just as we wrap up, where can our listeners go to learn more about you and your lab and the work that you're doing at Together?
Yeah, yeah.
First, thanks so much for having me.
It's been a really, really fun conversation and really glad to hear your perspective too on how folks are adapting to these new worlds.
So I'm on Twitter.
I'm real Danfu on Twitter, so you can follow me there.
When the lab puts stuff out, I'll tweet and release that.
Together we also will put out research blogs and different things at different various cadences.
So yeah, you can follow me there on Twitter.
That's probably the easiest way to find me.
Amazing.
We'll include links in the show notes and I'll definitely be paying attention to the research lab as well for stuff coming out of your mind.
And I appreciate again, you lending us some time to give us a chat.
And to those listening, obviously, if you made it this far, you loved this conversation.
You're a total nerd about the intersection of research and engineering.
So you should go find wherever you listen to this, whether it's on a podcast or newsletter, give us a like or a comment.
come find Dan or I on social media, give us a poke or let us know what you thought about today.
And Dan, thanks again for coming on Dev Interrupted.
It was a pleasure to host you.
Thanks so much for having me.
It was a lot of fun to join.