# AI Compute Compensation and Agentic Engineering Playbooks

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

## Transcript

So Ben, did you hear that Meta acquired maltbook?
Oh yeah.
I mean I I've I heard it too many times at this point.
It seems like everyone wants to talk about it.
What's Mark Zuckerberg's like obsession with monetizing personal relationships with AI?
Like what's up, what's up with that?
Like it just feels like this is another step in that journey.
I don't know.
What do you think?
I mean, what do you mean?
It's it's the perfect thing to add to his repertoire, another website.
Yeah, I mean I get users pretending to be people.
I think that it's uh another notch in his belt for sure.
But actually, I think it's really interesting to think that uh it would be something that is uh hungry for an acquisition.
And not nothing in my mind really struck me as like, oh, I want to buy malt book.
Yeah, I'm I'm like, what what insane experiment can I create that some company will come along and buy?
Well I do think there's an interesting telling there about maybe this being like a wink to where things are going and like the new consumer economy, because obviously you have these advertisers in their ad marketplace making the bet that in the future they're gonna be selling to your agents more than they're gonna be selling to you.
So you might as well start owning the places where those agents go.
And it could be a really interesting kind of transformation of the internet, just depending on if it's artificial readers end up outnumbering its real ones.
Um kind of makes me wonder like what happens.
Can you just make agents that create enough value on their own that they become like an acquirable target?
But yeah, I'm just like reflecting on like how chaotic like this like open claw like has made the this the AI space, you know, like like its inventor went to open AI.
Now we have like the social network that was spawned out of it that's gone on to meta.
But then like you also just have like companies like Anthropic over here that are just like quietly building co-work and like using all the same conventions, you know, but that that are letting like smart people like you and me just like solve our own problems with them, you know, rather than having to like get a product out of it or something.
But it's also a difference in the organizations.
Anthropic somewhere, I think they built co-work in what like 10, 12 days or something.
Meta superintelligence lab, that's a place where a bunch of smart people and interesting ideas go never to be heard from again.
So far so far it's really just the Willy Wonka factory of AI.
And so uh I just don't know what this means, even for Motebook, but definitely something to watch.
Yeah.
Well, anyways, welcome to the Friday deploy.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Zickler.
Here's this week's news getting paid in GPU time, a playbook for harness engineering, a spade of outages, including incidents tied to the use of AI tools.
And are you falling behind if you're not running agents every minute of the hour?
And you let's just start right at the top of that and get talk about these people who are are are getting paid in AI compute.
What's the story?
Yeah, so open AI's Greg Brockman said inference compute is increasingly driving software productivity, but also becoming part of compensation packages.
And one submission on the levels that FYI even listed a co-pilot subscription as a benefit.
Uh, so it's really interesting to think that AI usage could represent uh upwards of even 20% of total engineering compensation based on some uh VC's kind of estimates on this news.
Yeah, you know, I think both of us can kind of relate to this.
Uh, you know, we've we've had discussions about how like quickly just raw token costs can become like one of our biggest budget needs.
Uh, and it can just like suddenly ramp up like overnight once we we find a new workflow that we're going to use.
I mean, the moment that I started like doing age and orchestration, you know, I I immediately felt this like anxiety around my token usage limits.
Like, you know, I didn't really like being in this place where I had to like temper my goals and expectations around what I could think what I thought I could fit into like a five-hour token session.
There was a number in here that I I saw that it the uh there was an estimate that like token costs could reach a level of like 20% of an employee's salary.
You know, I think just looking at the horizon that exists today, like if the trajectory continues, I I could see that being a reality that like you actually would be consuming so many tokens that it would be a significant portion of the cost of hiring someone.
So yeah, I don't know, I don't know.
What do you think, Andrew?
Like, especially around this, like it being a part of compensation packages.
As an engineer and someone who consumes a lot of tokens, actually, I think that this whole idea is totally unacceptable.
And it flies in the face of what I think uh the idea that the inferences unlocking for companies is supposed to be doing.
You know, we've talked extensively on the show about the value transfer of being a 10x, 100x engineer and using all of that time and inference costs to create benefits that ultimately get captured by your employer.
That's the that's the structure in which we work inside.
And so this is like telling somebody working in the dot com boom that they're gonna get paid in bandwidth.
You know, if you want me to buy more tokens or want me to be more on the cutting edge of whatever technologies we're using, then uh make that infinitely available to me as part of my job isn't part of the narrative that these cut teams are supposed to be getting smaller because one person's doing five, 20 persons people's work.
So why wouldn't they have five or 20 persons people's budget?
It it doesn't make sense to me to tie it into a compensation package.
Uh, I think it's extremely accessible to get uh access to a near infinite amount of tokens without breaking the bank.
And uh frankly, a lot of engineers are already tapping into both sides of this with their work consumption and their personal consumption anyway.
So the idea of trying to make it part of the compensation doesn't make sense.
As much as it is uh you should definitely roll it into the cost of the employee.
But that's kind of the agentic workforce we're stepping into.
Maybe that employee is two or three times more expensive or something.
Uh, and a large part of that's going to their tokens, but you're getting 5x the output, 10x the output.
And so uh for me, I think it's a fascinating.
It made me actually think of the song uh where he's singing, like, oh, you load 16 tons and what do you get in another day older and deeper in debt?
But it's like in this case, you just get what, a co-pilot subscription?
Like, no, it's unacceptable to me.
Yeah, yeah.
Uh yeah, you know, I think that's a good that's a good way to frame it.
Like it really is something that, you know, I I I often compared like uh in the early days a co-pilot script subscription to like a grammar checking software subscription.
Like we use Grammarly, for example.
And it's like we we don't really like uh talk about whether or not it's something I should have.
Like we don't really debate it.
You know, it's just I I walk in the door at any job and it's something that I'm given because we recognize that it's something that makes me more productive uh to have access to that.
So the story really just highlights just how in demand all of these services really are becoming at this point.
Uh and not only that, but how much value we we're extracting from them now when we when you figure out how to do agent orchestration.
So uh yeah, it's an interesting conversation nonetheless.
For sure.
All right.
So moving into our next story.
So this story covers the emerging harness engineering playbook.
And I really like this article because I think it illustrates a lot of great examples of what we're describing of these teams that need high token costs or high token consumption because of the thing, the types of things that they're doing.
Uh, so this this article comes from friend of show, Charlie Gao.
He walks through a whole bunch of situations of of engineering teams using agentic AI to accomplish some pretty amazing things.
Like at OpenAI, there's a team that builds a one million line products, internal product with over a few months with just three engineers.
You know, Stripe is doing tons of agentic PRs that are uh being produced every single week.
So, Andrew, I'm curious what you think about this article after reading it.
This article is a really great, uh nuanced breakdown of the challenges that are facing engineers right now because we've talked a lot on the show, and everyone's heard this saying a lot of times of engineers have to become managers, right?
And engineers need to think in the level of how their manager would typically assign and and and figure out what's going to have the highest impact of work, right?
And that kind of uh transformation, how you think about your work is is one journey.
But then there's another journey happening here as well.
Is once you've decided what needs to happen and you're acting upon it, it's more than just telling your agents to do it like you know exactly what to do.
You also have to curate the right environment, give them the right tools and set the right expectations so that they can not only get to where they need to go eventually, but do it quickly, safely and on task.
Because as we've talked about, like over 70% of agentic coding time is typically spent refactoring past agents' work.
And so the idea of having proper alignment and guardrails from the very beginning is so important.
And that's what this article dives into.
The idea of harness engineering being that you have to manage the work environment just as much as you're managing the work that the agents are doing.
And acknowledging that it's not a step one, step two process.
They feed into each other.
You switch between them and they enrich each other.
And there's actually as much as there is to learn and reflect on from engineering managers and product leaders and how they think about and delegate technical work.
There's also a lot to think about just in general group practices, leadership practices.
If you've ever been in front of a group and doing a presentation, leading a team in any capacity, you know that you have to put the right tools in your people's hands in order for them to get the job done.
And this is what's now happening on a micro level, not just on the engineer level, but inside all of their individual projects.
And this article dives into some of the nuances of that skill of building that harness.
Yeah, and specifically some of the practices that stood out to me is uh, you know, first of all, like planning is the new coding.
And, you know, I've been keeping this phrase in my head be intentional.
Like I keep thinking that at all times as I'm building stuff because I found that's that's the way that I ensure that the agents that I'm operating are moving in the direction that I want them to move.
Uh there's also advice on documentation being your new system of record.
You know, everything needs to be documented and stored.
And, you know, I think historical context for learning is just as important as like knowledge context.
You know, you need to build that the historical reference of all of the decisions that have been made, why they were made and how it impacts things moving forward.
And you you need that chain of decisions.
Uh, but most of all, there's some, you know, the advice that I think we all need to just really, really keep at the center of this is just avoid the AI slob.
Like you should have higher standards for AI generated code than you do for human-generated code.
And I think that's one of the missing nuances behind when you hear all these these executives out there that are like, we we have 70% of our code being generated by AI.
And they don't always mention the part where they also include substantially more testing for that code than they've ever required in the past.
So it's just naturally generating far larger volumes of code than than uh what they would otherwise.
So yeah, there's a ton of great advice in this.
Uh, and yeah, uh definitely encourage everyone listening to go read the the article.
Yeah.
All right.
Well, let's let's go let's move on to a topic that uh we we seem to be coming back to over and over here on dev interrupted.
And I I kind of feel like it's gonna keep the story's gonna keep going for a little while.
Uh this comes from Gary Marcus about these recent Amazon outages that have happened.
These types of things probably are already happening like all the time, but it really only makes the news when it's a company like AWS that it happens to.
So yeah, Angelo, well, what's what's your take on this this article?
Yeah, I think that's an important distinction.
The call out is that this kind of process and incident in reality, this growing pain is happening everywhere.
It's just when you're Amazon, it's an inescapable, uh, you know, when it affects you and your customers.
All of that said, I think that this is like a really interesting sign of like how much of the growing pains of developing those new skills around understanding what needs to be done and then also creating the right environment for it to be done.
Uh, as folks build those dual skills, you kind of get this awkward one step forward, one step back, you know, lurching kind of motion.
And I think that's what you're seeing.
Is like from this, there's obviously going to be learnings that will produce new guardrails, better environments, more strict uh security, a deeper understanding also of how the tools that are getting uh put on put on your team are being utilized and adopted.
I really think that's like a calling card here is like if you have incidents like this that are either visible or you think are happening under the surface, it's really important to understand how that does tie to your organization's AI velocity and what tools you're using and having a scope of, you know, uh if there's a problem that's happening in an A in an because of like an agentic process, being able to implement guardrails to prevent it is something that's so achievable now in a way that actually was fundamentally harder when you were trying to implement these guardrails with humans, the human engineers.
And so I think there's a lot of interesting ground to explore in being able to understand like how uh AI adoption is tied around these kinds of incidents and then actually be able to create the best working environment for it moving forward.
It's going to be an uncomfortable process because we're effectively reinventing the SDLC.
Yeah, yeah.
I think just last week I mentioned the you know, the three steps forward, two steps back with with AI, or just technology progression in general.
And I've seen this as I've tried to adopt all the latest tooling.
There's basic capabilities that you would expect to have or want to have that just aren't there yet because the tooling is still like very immature, you know, even down to just like giving basic permissions, like allowing AI to perform certain actions on certain parts of your your code or or your workspace versus other parts of that workspace.
The tooling to do that isn't isn't always in place without, you know, again, being very intentional, intentional about putting it in place in in the first place.
So yeah, there's a lot of just I feel like fundamental capabilities that we're all relearning at this point.
And it's even more risky when you when you're doing this in the hands of people who don't have a lot of experience.
If you have, you know, more junior engineers or or or uh something like that, or just less structure around your engineering process.
Maybe it's just your your engineering team as a whole is less mature.
Uh, you know, that op those are the types of things that open up these these risks.
So uh at the end of our lineup here, I want to end it on a fun one.
This is a blog post from George Hott saying uh, you know, every minute you aren't running 69 agents, you're falling behind.
But it's really just kidding.
It's a nod nod to the reality of the kind of a toxic race that we all feel like we're running in sometimes.
The idea that if you're not running a hundred agents right now, then you're falling behind or you're not changing the game or you're going to be replaced.
You know, it's it's definitely a a time of like very breakneck velocity, right?
And at times it can feel like there's no relief from it because you have to keep running.
And I think that this is like a nod to like acknowledging that reality that we're all running this relay, figuring out where it goes.
But he also dives into a little bit about if you know if you are running that race, if you are uh waking up every day and and and doing your best to figure out where it's all going to go, then you're already in such a great position.
What did you think of this one, Ben?
You know, I I like you said I think it's just something that uh it's just some the type of thing that we should always be thinking about just for our own mental health, for the health of our teams, for our companies it is very tempting.
Like it's intoxicating to work with AI and see how quickly it can help you move.
And it's it's really fun and really great, but it's also very taxing.
There definitely is a lot of pressure to adopt some of which is reasonable, but I think also a lot of which is often unreasonable.
So I think it's really important that, you know, again, I'm going to keep saying this for for I don't know how many weeks, but for many more weeks ahead, I think, you know, be intentional.
Like if you're going to to accelerate yourself with AI, make sure there's a clear intention behind it and you know exactly what you want to achieve with that and what to what to do with the outcomes from from what you're doing.
And I think that's the best way to just, you know, adopt a AI in a healthy way that that helps you move faster without like just scattering you to the wind with all of these different priorities.
And I think a strategy for for doing that is the being mindful about how you are building your skills and what you're working towards.
And ultimately what you should be thinking about is using these newfound abilities and multipliers to remove complexity from your job and your life, not to add it, because that's only going to make that breakneck pace more untenable and more unmanageable.
But the there's actually such a bigger opportunity to use that to pair away things that before we took for granted that before we used as crutches that were our own human arnesses in a world before AI and actually reinvent um ourselves in a simpler way so that you can be more impactful in very specific ways.
I think that's kind of the call to action.
Like if, you know, you don't need to feel like you need to have a hundred agents running at all time.
It's like there's so many people who make things and they never use them, never ship them.
Get really close to a problem you're really passionate about, and then uh you'll be shocked at how much leverage you can apply to change it now.
Yeah, I think I think if you if you focus on leveraging human expertise, I think that's sort of the answer to this.
Find your experts and give help them or have them use AI to remove the things that prevent them from spending their time being an expert.
You know, I think that's really a a healthy way to approach this because it it frees up people for the, you know, I think most people they want to engage in higher order work.
They don't want to be toiling away at manual effort and and the like.
So I think naturally if you focus on freeing up your experts to be experts, it's a really healthy way to leverage AI.
Well said.
Yeah.
And speaking of leveraging AI, how what are your what are your agents up to this week, Andrew?
Ugh you got me.
They're running actually right now.
Oh, they were running, but during our call.
Um I hope it's not I hope it's not 70 agents, you know, because that would be it's definitely not 70 agents.
Uh but in this case, uh, it's one of those human obstacle things where they're basically up in arms and having a revolt in my little software factory until I come and click the human button.
Uh, it's just one of those warnings.
What about you, Ben?
Yeah.
Well, I so I'm I'm setting up a new laptop right now, and and I've really decided to be intentional again and and like set this my experience up from scratch in a way that is more agent forward.
Like I want to, I want to, as I'm working using my laptop day to day, I want everything I'm doing to be supporting the agentic systems that I'm building.
So yeah, I'm adopting a lot of new tools, a lot of new workflows.
Like I've been spending a lot of time with Claude Skills and Holy Cows.
It's it's a lot of fun.
But again, getting back to these like missing fundamental components, like file permissions is like quickly becoming a nightmare.
And I'm like, man, do I need to like vibe code a file permission system to like like manage what the stuff that I give to my AI?
Folks, he's in dangerous territory of listening to him talk about vibe coding a file permission system.
Somebody take cowork away from it.
Yeah, I know.
I know.
I've seen you building all these like fancy apps to manage the deterministic layer of of your agents, and and I'm not quite ready to get to that for just like my personal work, but yeah, I need something something like that that gives me yeah, because right now it's like all the tools just want like full access to everything, or like they just don't get access, you know, and I and yeah, that's that's how you get these horrible outages with a AWS or you know, then and the like.
Like that's how you end up with that stuff.
Ain't that the truth?
Except in your case, an outage on your laptop just means you can't join our zoom call.
So the stakes are a little lower.
But yeah, well, I mean, I also don't want to just like delete all of our content accidentally, you know.
That would be pretty horrible.
All right, folks.
Well, if next week there's no podcast, it's because Ben's agents deleted all of the dev interrupted production work that I built for the last year.
But regardless, it was really great chatting with you again this week, Ben, and everyone else.
I hope you have a great weekend.
AI helps your developers write more code faster.
Here's the problem: your review process hasn't sped up.
The queue grows, reviewers get burnt out, cycle time stalls.
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.