# AI Model Economics and Sustainable Engineering Practices

**Podcast:** Dev Interrupted
**Published:** 2026-06-12

## Transcript

So, Andrew, bots just continue to take over the Internet, don't they?
Seems like they're everywhere now.
Can't really escape them.
Seems like most websites can't escape them either.
Yeah, we didn't want to call this as an official story because it's kind of outside of our wheelhouse.
But yeah, we've been reading this week just about how AI bots are just taking over the Internet now.
And humans may actually now be in the minority of interactions on the Internet, which...
As a longtime Reddit user, I've just gotten used to that by now.
I feel like it's been that way for quite some time.
But yeah, it is interesting to just see how many bots are out there on the internet right now.
And I think the one thing that we should bring up is it is important for every engineering leader that's listening to this to be aware of this trend because security threats are really starting to change now.
Years ago...
We've always had this term, and it's kind of a derogatory term, of script kitties.
And this is a term used to describe low-experience hackers who would go download a script from some malicious website and then go use it to try to hack into companies with bad security practices.
But now you can have your AI generate the script for you if you can trick it or something.
If you can manage to trick it, the guardrails on these kinds of things.
Models are definitely getting better, which is much to my relief, but it still doesn't protect us from the fact that the reality is more than half of all internet traffic now is from a bot as opposed to a human.
It's officially their space.
Like you said, there's a lot of downstream consequences of that that I think are going to be more profound.
We've covered recently on the show about how most new websites now are AI generated.
as opposed to human created, which has its own unique facets about like archiving the web and how we train these models on the web, the living web itself.
You kind of get this phenomenon where the exhaust pipe is feeding the production input.
And the exhaust pipe is, we're kind of like, that's not necessarily the stuff you want to be breathing.
And so it's not the best kind of content that's going to...
be enriched over time, you're going to lose that human diversity.
So I think that's the biggest flag here is like, wow, if bots are now half of all traffic, we do need to change how websites are served and delivered.
Sure.
And a lot of those experiences are moving around.
But then what does it mean for when we even look at like traffic data?
Like what is an audience anymore?
Who is your audience?
Yeah.
Well, welcome to the Friday Deploy brought to you by Linear B, the engineering productivity platform that helps you wrangle agents in your SDLC.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week, we are covering why Andrew is absolutely obsessed with the fabulous Mr.
Fable.
Is token maxing about to die and cleaning up after AI of rock stars?
We got a really great lineup of stories today.
But let's just get right into the story that is catching everyone's attention, and that is the launch of Fable 5 from Anthropic.
Andrew, what's going on here?
And why are you so excited?
Well, you know, this is a first, at least in recent history, where Anthropik is dropping a bottle while we're not in here actively recording, so we don't get to, like, share our immediate thoughts about what happened.
We actually get to cover it.
I actually get to cover it.
So I actually got a really great about 72 hours at this point of maxing out all of my usage sessions that have been available.
And playing around with the new Fable 5 has been really eye-opening, not only about the direction.
in which all of this is going with bigger and bigger steps every model release, but also about the opportunities.
Because of all of the ground we've already covered as burgeoning AI engineers, we've carried a lot of like cruft and a lot of things into our current way of working.
And when a big next level foundation model like this comes out, which is what Fable is, it represents an opportunity to turn and reflect inward.
right, on your practices.
And so that's what I've been doing with Fable is reviewing how I have been doing processes of the past with Opus and with other things that I do with Sonnet as well, really doing a thorough audit.
on like my harness and my skills and my hooks and what matters when I start a project.
And the reason for this is twofold.
One is we're not going to have Fable forever because it's only available to accounts and subscription accounts right now until like the end of the month.
And then it's going to become an API based consumption.
And it's like $50 per million tokens because it's that smart.
So you're talking about a really expensive model to use.
So you have this limited window to.
churn it through all of the stuff you've been working on to get the improvements baked in so that when the model's taken away and it's more expensive and you have to now be metered with your usage of it, you still have the benefits of it baked in at a time that it was subsidized.
So that's something that I've really been keeping front of mind.
If you have access to Fable and you haven't used it and turned inward on your own tooling, on your own practices yet, this is my call to action to you.
That's like the most imperative thing that you can do with access to this tool because that's how you're going to get the benefits.
that carry you into the future.
But Ben, what's been bouncing around in your head about Fable and how you've been seeing folks in the industry react to it?
Well, first of all, I'm just a little upset that you get to continue having your I told you so that AI costs are continuing to climb across the board.
Because, yeah, I think it's important to point out that this is only a temporary availability to standard, you know, Claude subscriptions.
In a couple of weeks, they're planning to make it only available via the API.
And, you know, I think some people reading this is like it's too expensive for them to give to cloud users.
And I kind of I kind of agree with that.
But I also just know that like with the way Anthropic operates, you know, they always seem to have like really fast follows whenever they release some sort of new big model.
So, you know, think about when when Opus 4.6 came out, like that was a big deal and cost a lot at the time.
And then very quickly Sonnet 4.6 came out and then Opus 4.7 came out.
And like, you know, so I think that they probably will have versions of this that follow very quickly that do that work similarly to Fable, but at a much more cost efficient way.
So, yeah, so I think it's just the first iteration.
You know, we're going to see a lot of these Mythos based models, I think, coming out in pretty quick order.
I think, you know, and I haven't personally had a lot of time to spend with it yet.
So I've, you know, mostly just heard from your perspective, but then also let's get into this next article too, because it does a really great job at breaking down what this model is really good at.
So yeah, as we know, we'll include a link to this article, but it's about what it feels like to work with these Mythos models.
So Fable, again, is the first publicly released Mythos-based AI model.
has a huge capability jump in terms of what it can do.
In particular, it's really good at spinning up fleets of sub-agents that can paralyze work.
And anyone that's been operating in this space for the last six months knows that sub-agent orchestration is like the name of the game right now.
And in particular...
They have created, I forget the term that they use for it, but it's like sub-agents, the adversarial sub-agents, sub-agents that challenge the situation rather than just going along with the work.
So, you know, I really think this is probably less of a like the model itself.
Like I'm sure the model itself has gotten better with this release, but it really seems like it's the application of the model that is really fundamentally changing.
And creating new opportunities.
And this article linked to has a lot of cool examples of the author playing around with Fable, seeing what it's good at, what it can do that models previously couldn't do.
Like, for example, there was an isochronic map.
So it's a map that you set a location and then it shows you how long it would take to travel to the rest of the world.
And Fable was able to produce this with a little bit of guidance.
And that's an immense challenge.
You have to understand so many different things to not only calculate the travel time for something, but to understand things like flight patterns and how do you navigate terrain that doesn't have real roads, that kind of stuff.
And so, yeah.
What did you think about this article, Andrew?
Does it match your experience with Fable so far?
Yes, I really liked that kind of how they reasoned with like the reality of operating the model.
Because if, you know, using if using Sonnet was like riding a bicycle and using Opus as like riding a horse, it kind of feels like, you know, riding Fable or a Mythos class model is like being a dragon.
Like you're trying to go somewhere, but it could just as easily torch down a village.
And that's just not what you're looking to do.
So you kind of have the reins on it.
You know, it's a dragon.
It has wingspan.
It can go a lot of really compelling places you couldn't go on a horse.
And I think that's the really exciting thing about using and experimenting with it and why I started with, you know, you should be using it to reflect inward on your processes because it's going to help you find crutches and cruft and bugs and...
baggage and wrong assumptions and practices that are 90% of the way there and let's get them to 100, right?
And baking in all of that value is like the name of the game right now.
Only you can do that for your harness with the technology that's available and you should fully expect.
that this kind of release cadence is going to be the norm, where you get like a next class capability foundation model that can just net new perform so much better on a wide variety of stuff.
It's available in a limited capacity, and then it's available in a more expensive tier because it's not supposed to be your daily driver.
You're not using the Dragon to go get your mail.
from the mailbox, right?
And so it's like, you need to understand when you use a mythos kind of model and when you use a sonnet, when you even go all the way down to haiku or whatever your favorite flavor of model foundation family is.
They all come in a spectrum of capabilities.
And this is a reminder to folks as engineers that you have to be expecting that those costs will go up, that the access to them will become more prohibitive, it will become more expensive, you'll be under more pressure to prove ROI, and you'll have less excuses to hide behind why you're using expensive models when you could be using cheaper ones as the spectrum becomes wider and wider.
So I think that this article does a really great job at like...
showing how you get these next level jumps in the way that you work that allow you to kind of like almost scaffold a new kind of harness, a special harness, right?
This is the one that goes on your dragon, not the one that goes on your horse.
It maybe takes a different shape.
You maybe need less and maybe you use it to do a totally different thing.
And that's what you have to figure out in working with the model.
I will say just experimenting with it, its capabilities just seem just like a leap better.
than anything before, which is then also a great, great reminder and something that's not talked about here in the article and frankly always gets brushed over when these conversations come up.
You should have it also do a security audit on your systems, on your applications, on the things that you use.
Imagine that you have 10 days right now to find all of those weird hidden bugs inside of your applications or in your APIs or that make you weaker.
Imagine that people that are on the attacker side have those same 10 days and they're going to have a bigger budget and patience to pay for the API tokens afterwards.
So I think the dangers and the opportunities shift as well.
So you have to kind of bring a little game theory to experimenting and using these models.
And this also really hits the nail on the head.
But that's just a reminder for folks.
Yeah.
And one last point I want to make on this is that, you know, Fable.
clearly dramatically reduces the amount of effort it takes to build complex software.
However, you know, the author pointed out that to deploy something like this to production, you still need software engineers that can make, can build it in a way that's secure and efficient and can work at scale in production.
So, you know, and if anything...
Demand for software engineers could potentially increase substantially because now you have everyone just building their own applications.
More and more people can now contribute to your code base.
With that volume comes increased need for people who are experts at building and maintaining code to make sure that it's all at a high quality.
So the author also kind of points out that this model feels more like a black box in the past.
You know, because it's making so many decisions now for every task that it's practically impossible to follow everything that it's doing to validate it.
So, you know, it's certainly going to bring new challenges, new opportunities.
But yeah, it's exciting times.
I always love getting new models like this.
Indeed.
All right.
Now let's talk about what people are doing with these models, Andrew.
So we have Sam and Altman out there, you know, fan of the show, of course.
Saying that OpenAI's top spender is using 100 billion tokens per month.
And that's not even the world leader.
What's going on here, Andrew?
What's in this article?
Yes.
So this article from.
You know, talking about Sam Altman, longtime listener and big fan of Dev Interrupted, of course, is really cracking open the truth about token consumption across the board.
That is, you know, we think and we talk in this engineering world about how we use it to generate code and improve our delivery and figure out what we're shipping and all that beautiful stuff.
It's easy to forget that the rest of the world is doing that, too.
Every industry is experimenting with that.
Every human is figuring out what that means for their personal life.
And while there's a wide array of reactions and adoption to AI in general public life, it's undeniable that that technology is permeating into all of these places that we live and we work and we use.
This talks about how token spend and token consumption is not just bounded by a developer and their capabilities.
It's bounded to the human, right?
Token consumption and usage is becoming more of a universal human thing for folks that are connected and online.
Which, of course, a good reminder that less than half of the world is connected to the internet.
So, again, we're dealing with a bubble within a bubble.
But the reality is that using tokens and consuming tokens is starting to become like a flex.
of knowledge working, and of operating with these tools.
And like any other thing that becomes tracked, it becomes easily gamified.
You get this weird morphed world that we've been talking about a lot on the show around token maxing and leaderboards and, oh, this engineer's using 100,000 million tokens in whatever period of time.
And that's so amazing.
That's so cool.
They're so agentic.
But the reality is, is that what you get out of those tokens is totally, totally a variable about what you're putting into it and about the world in which those tokens are getting consumed.
And so, like, I think this is a good reminder that, like, token consumption as a measurement is, like, kind of a...
It's kind of a directionless stat.
You have to anchor it with something to understand what those tokens are getting used for.
But also, too, like, if you're spending all of that money on tokens, I doubt that's going to be sustainable with the way that things are trending with token costs.
And while the average human consumer is not that worried about that because it's baked into and rolled into and embedded inside all of these subscriptions and package deals and things that they buy and use.
In the engineering world, where we use it like a water faucet, That's much more important to us to understand.
So a good reminder that token consumption, not a great thing to just anchor to all by itself.
Yeah, I'll go even further and just say I'm ready for this token maxing culture to just formally die off.
In fact, I would love to help kill this culture.
Yeah, I mean, you know, there's some interesting numbers in this.
So like six years ago, the biggest open AI token spender was spending about 100,000 tokens a month.
which probably felt like a lot back then.
That is now the median.
So the typical OpenAI user is now consuming what used to be the maximum per month.
And yeah, we mentioned that the top leader is 100 billion tokens per month.
The creator of OpenClaw is out there saying he spent $1.3 million in tokens in one month.
I mean, Jeffrey Emanuel, who created Beads Rust that I talk about nonstop on the show.
Last I checked in with him, he had 16 Claude Max accounts.
My goodness.
That's so wild.
And, you know, in companies like OpenAI, they like have this incentive to encourage you to consume more and more tokens because that's how they make their money, you know, assuming you're doing it through an API.
But I, you know, I just don't think, I don't see how this is sustainable.
These spending amounts just seem so.
unrealistic that you really can't just, you can't expect a typical developer to generate enough value to justify like a million dollar per month token budget.
Like that just seems kind of insane to me.
And, you know, we're covering this topic a lot right now at Dev Interrupted and at Linear B.
You know, in fact, we have a workshop coming up about life beyond token maxing.
You know, we want to help organizations understand how to measure efficiency.
In an era where everyone is just recklessly and inefficiently spending their tokens, this era is not going to last forever.
The bill is starting to come due for these tools, and you need to have a plan for how you are going to continue to measure success with AI that doesn't involve just burning more tokens.
So yeah, we'll include a signup link to that workshop in the show notes.
And yeah, we have lots more content coming down the pipeline on this topic of token maxing.
Yes, come hang out with Ben and I so we can, you know, dump on all this token maxing stuff and get it all out in the open.
We're going to have lots of good discussions there.
Exactly, exactly.
And, you know, look, the age of AI experimentation has been a lot of fun.
You know, I still enjoy finding new and creative ways to just burn a whole bunch of tokens.
It's a lot of fun, especially when it results in something that like...
is like really mean, creates a meaningful impact for me.
But there's also plenty of projects where I just burn a whole bunch of tokens and don't really accomplish anything too.
Like, let's just dig a hole.
Yeah.
So, you know, we're getting to a stage where we need to start thinking more and more about how to sustainably and efficiently use AI.
So stay tuned.
We got lots more content coming on that, including our next article that I want to cover.
And that's about how this company cut our AI spend in half.
And they even went as far to say token maxing is dead, which I would, I hope so, but I don't think that's the truth yet.
But what's this article about, Andrew?
Yeah, so this article about token maxing being dead and AI spend and how you get a handle on it comes to us from OnlyCFO, which is an amazing blog if you're not following it, about how financial leaders within the tech space think about leading their engineering orgs and understanding the value of what they're shipping.
And it's never been more timely in a world like right now with AI and the costs rising.
And this article takes a really strong lens to AI token consumption, how it's measured.
And ultimately, it comes down to model routing being the secret.
nexus by which you've fixed this problem.
And we've talked about this on the show quite a bit.
The idea of not every request needs to go to your most capable model.
And some long-running autonomous things are really scaffolded in a deterministic way.
They need a different kind of model.
Understanding what tool to bring to the problem and what level knowledge to utilize is going to be part of optimizing the cost efficiency of this.
You know, the author of this article, he talks about how using a model router and educating developers and routing workflows through this model router that can intelligently source to the level of model needed can dramatically.
cut costs and allow you also to to get better and smarter estimates on what future costs might be, which is a really interesting uplift that you get out of having this system in place because, you know, the workflows and the processes that have worked in the past.
And then you can also then connect that with engineering health and delivery data throughput and quality and understand, you know, what happens to that code afterwards.
And then you can validate that in the middle, choosing this model for this task and it resulted in this kind of level.
performance downstream is how you can then, you know, pin it to a model that you can stick with.
And like the costs on this are really tactical and they don't require a lot of engineering lift.
It's just about understanding the cost efficiency problem underneath and figuring out the best tooling and optimizing for costs just as much as you're optimizing for accuracy.
Because I think like...
What this also really reminds us against is it's so tempting, especially right now, as I call them dragon class models like Fable come into the world.
It's really tempting to use them to do everything, like go check the mail and make a hamburger and whatever.
But the reality is that you need to be really smart about when and how you use it.
This is exactly what this article hits a nail on.
If you've been listening to everything we've said so far in this discussion, you know that's what we've really been hammering.
And if you haven't started This is your reminder, but this is also your roadmap.
You should send this to somebody who is financially responsible for budgets and understanding how the models are adopted and get them on the same page as you because this article is a really great Rosetta Stone between you and that non-technical financial leader to be able to talk about how you solve token maxing with engineering and measure it for long term.
Yeah, and this is something we've been hearing in conversations with a lot of Linear B customers is that like AI cost is like top of mind for everyone right now, particularly as, you know, like we've covered here, like Copilot changes to usage based pricing.
Model costs just continue to rise like nonstop.
This article really does have some some really great tips on just how to get started being more efficient with your token spend.
So, you know, you mentioned, you know, routing AI to cheaper models.
You know, Haiku is about a fifth the cost of Opus if you're talking about Claude.
So, you know, if you're just renaming a file, like use Haiku because it can do it and it's not going to cost you a whole bunch of money.
Or use the command line.
Yeah.
But, you know, there's prompt catching for repetitive tasks.
So you're not always burning a whole bunch of input tokens on the same task over and over again.
And then you should also just be tracking like your AI spends.
Like we've been starting to roll this out with a lot of linear B customers.
And it's a really powerful way of looking at your work.
Like if you know exactly how many tokens went into a project management task to create a new feature, or if you can see which teams are spending the most money on tokens, These are all great ways to look to see where you may have potential opportunities for efficiency gains.
And of course, there's just a lot of things that you can train your employees on, like why using new chat threads is important, because every time you post another response into an existing chat thread, it pulls that entire thread into its context and burns extra tokens.
I think this is the year that token maxing dies.
I don't necessarily agree that it is dead yet, but I think it is on its way to, as these costs continue to increase, this is just going to become a recurring theme at practically every company out there.
So yeah, make sure you come to our workshop.
We're going to be talking about all of this in depth.
We're going to help you end your token maxing practice at your company.
And we're going to give you solutions that you look for more sustainable ways to measure the impact of AI.
So yeah, make sure you sign up.
More to come.
All right, Andrew, let's talk about cleaning up after AI rockstar developers.
And as someone who feels like a rockstar often, this really resonated with me.
Indeed.
Likewise, when I read this one, I was like, oh, I'm feeling awfully called out in this article.
This one was a total joy to read.
If you haven't judged by the title, it's really just as much as it sounds.
The idea that, you know, an AI developer, the rock star on the team who comes in, they ship a lot and maybe they make some new kinds of changes and then they leave, right?
It's the idea of somebody coming in and being clever and fast and producing maybe really...
good for the moment, but hard to maintain over time code, and then they leave.
You know, that's like what a rock star does.
They roll up into your town, they do their rock show performance, and then they bounce.
And when you have a world in engineering where you're working with AI tools...
humans that are doing that work are more removed from the work being done than ever before.
So, and now when the rockstar developer comes in and slams a bunch of code and then gets transferred off your team, you're not left with like, oh, we have this crazy Jenga tower that's like driving this, you know, super great downstream value, but now it's just a total pain for us to maintain.
Instead, now you just have this big, mysterious black box.
that does stuff.
And so like, that's the biggest problem is that you don't get good documentation.
You don't get the sessions preserved.
You don't get transcripts.
You don't get the practices from the org necessarily baked into every layer of the process.
And as soon as you start to examine and look at what's been shipped and how do we keep the lights on, you know, there starts to be a lot of questions.
You start to doubt the things that you...
thought you understood more about it and it becomes like this big gorgian knot to like cut or untie like ultimately what this article gets at is that like vibe coded databases, they end up in this horrible state if they're not operated with a really close lens by an operator who understands the core domain problem, which fundamentally is something that a rockstar developer may struggle with because they come in and they ship that really innovative or interesting solution and then they usually move on to the next one.
And so balancing that with like, okay, you have this like...
precise kind of solution to how do we maintain it long term, you have to have those durable practices baked in.
Like, unfortunately, you have to slow down that rock star AI developer.
You have to throw guardrails in front of them.
And you're actually going to learn a lot about your guardrails and which ones need to be there and which ones work for this world and which ones don't by the way that they navigate.
in and around them.
Because the Rockstar developer wants to get the work done as best and quickly as possible.
And so ultimately what this author reminds us is that, you know, the human, the person, the decision manager, the domain expert, they need to stay in the driver's seat.
And you need to create small, incremental, reviewable snippets, which is totally antithetical to how the Rockstar wants to work.
Ultimately, this is a people in process kind of problem that you have to address by, I guess, sobering up your AI rockstar developers with the reality of shipping things long term and ultimately having just like better code hygiene practices.
So, yeah, I think this article does a great job at, you know, encapsulating how AI feels when you work with it.
You know, it really feels like somebody who is overqualified for every single task that you give it.
But I think what the real core of why there's some compounding effects of the problems that this rockstar AI developer creates is that, you know, models are designed to get to a solution as quickly as possible rather than building something that's sustainable for the long term.
And it's really just a problem of the sycophancy that AI has.
It values immediate solutions over long-term success.
It wants to come to a solution within the session and not leave a whole bunch of hanging threads for future sessions.
And there's really, I think, two problems that AI has created in this context.
And that is first, it has dropped the floor to becoming a rock star developer, quote unquote.
Basically, anyone can fake being able to write lots of code.
So now there's more.
Rockstar developers than ever before.
Like basically anyone who just wants to pick up an AI coding agent could become one of these types of developers.
And then second, it raised the ceiling of what those Rockstar developers can achieve.
You know, one of the classic hallmarks of being labeled a Rockstar developer is, as you mentioned, it's somebody who just moves as fast as possible without regard for how everyone else at the company will need to deal with their outputs.
And now with AI, you can do it at 10x the speed that you could before, potentially even more.
It really just comes down to how big your token budget is.
But there's some great advice.
You mentioned it.
Slow down.
If you find yourself lost and you don't understand what AI is doing to your code base, or if you see somebody on your team who's operating that way, it's a good time to just stop yourself and take a moment to understand the architecture and make sure that what you're doing is meeting your quality standards.
And implement controls to make sure that your AI agent is producing code at the quality that your team needs.
You know, these are all standard practices, but they become more important than ever.
And yeah, I think this article does a really good job at highlighting those issues.
Yeah, really could call it that it's easy for anyone to be that rock star developer.
I think that's kind of the struggle that we're all experiencing with our SDLC is that overnight, all of our engineers kind of developed into these.
their own version of a rock star version of themselves.
And so you have all of these like different practices and adoptions and different messes and the noise from all those different rock stars is really hard to hear the music through.
So that's like, there's a lot of opportunity here to like really come in and adjust and slow down, but ultimately just like having really good domain understanding.
of what you're doing, which can oftentimes best be happening through conversations and planning and stuff.
Like the stuff around and before the code is getting written.
Something that this article called out is like the idea of like this person comes in and they ship the whole problem and then before lunch and then they leave.
Like that way of working, it magnifies so many problems in an agentic space that we really have to put that practice aside and find new, more incremental ways of working.
Yeah.
Well, that's it for this week's episode.
If you've made it all the way to the end, that means you're a super fan.
And you know what super fans have to do?
They got to go out and they got to go engage with us wherever you're listening to us right now.
So whether that's giving us a like on the video or rating on the podcast, wherever you're listening to us, or just engage with us on LinkedIn or Substack.
We love to interact with our community.
And, you know, if you've enjoyed what we discussed today, you know, remember that it all really comes back to one major challenge that engineering teams are wrestling with right now.
AI is writing code faster than ever, and the SDLC is struggling to keep up.
And we're with Linear B.
Linear B is the engineering productivity platform that shows you exactly where AI speeds up delivery and where it stalls.
So we automate the bottleneck so that your team can ship faster and with total confidence.
If you want to see how Linear B can help your organization out, go head over to LinearB.io and learn some more.
So Andrew, thanks for joining today.
What are your agents up to this week?
Well, they are at their off-site spa retreat, reflecting and meditating and thinking about all of the things that they've done.
No, I'm just kidding.
I'm actually a flying fable over a bunch of cities and torching them.
The cities are actually my harnesses because we're finding lots of ways to improve them and bacon stuff for the long term.
So sure, maybe there's some smoldering piles of ashes on my machine right now.
Ultimately, what we're going to build out of it is going to be amazing.
I'm just waiting for my usage to reset.
Yeah, so you're just lighting Gastown on fire is what you're doing from the sound.
Oh, yeah.
Well, as you know, my Gastown sunk under the sea long, long ago.
But yeah, we're finding definitely new ways to work.
I'm having tons of fun using Fable to reinvent and explore stuff and also to scrutinize.
You know, I talked a little bit in the past about my scrutinized skill.
That's really been in full effect this week.
I'd say of all of my token consumption, most of it has been me.
telling Fable to go interrogate something about a process or a file or something.
And I'm compressing as much info out of that as I can with the Mac subscription that I do have before it's expensive.
Yeah.
Awesome.
Well, my agents are working with your agents a lot more.
It seems like we've really started to figure out some collaboration patterns that involve humans and agents and back and forth.
It's really kind of exciting.
It also does kind of expose just how.
No productivity tools have really caught up to this new reality yet.
We're just kind of hacking it all together on our own.
But hey, you know what?
We're all rockstar developers now.
We can just build it ourselves.
No, it's like we're sending these messengers to each other.
The way that we've been able to get this workflow for folks that if you haven't found a way to get good passing of handoffs between you and your agent and your agent and another person and their agent.
Unlocking that loop, especially on a knowledge working level, is incredible.
The ability for you and your agents to boil down all of the expertise and knowledge in your specific perspective and then hand it off in a really seamless way to another person and their agents to hammer it through the same process.
This is how knowledge working teams of the future are going to be built, and it's how they work.
And I think we're all experimenting right now to figure that out.
But it's been a blast to see the early vision of that, and I'm excited to see how far we can take it.
All right.
Thanks for joining us, everyone.
We'll see you next week.
See you next time.
existing productivity metrics frameworks to measure what matters in the AI era.
Everyone who registers for the event gets early access to our new guide on measuring efficiency in the AI-driven SDLC and controlling the executive conversation around these discussions.
The link is in the show notes.
Come hang out with us on June 25th.