Hello and welcome you all. Today I'm having Matas Rastiis
with me. Matas is Staff Software Engineer
at Uber's developer platform, and he's going to share how Uber
evaluates, deploys, and measures the best AI tools to make
developers as productive as possible.
Let's dig into it. Oh, and of course you can watch
the whole conversation on Spotify, YouTube and now even on
Apple Podcasts. Also, Mata's job description
change and he got a very cool promotion, so give him a shout
out on LinkedIn. Let's go.
Welcome to the podcast Mata's. Thank you so much for having me.
Thank you. I wanted to make an episode
about like the topic that I guess most companies are on to
right now, which is like how to augment the workforce, like how
to really get most of the AI tools and how to really
distribute them onto the workforce, onto the engineering
people to make most out of it. So I'm really glad to have you
here and talk about your work at Uber.
Awesome. Thanks for having me shoot away.
Before we dig into that, maybe we could have a quick
introduction to who you are and what.
Your job is sounds good. My name is Matos Restanos.
I work at Uber and we're specifically in the developer
platform organization of Uber. So we help engineers be more
productive in any way we can. Nowadays that's that means
enabling AI, you know, as as much and as fast as we can,
scaling engineers leverage to to new heights to where they can
now author, you know, two 3 * X more code than they could
before. Yeah.
And I work on a variety of different things that include,
you know, coding assistance, automatic test generation
tooling, AR guard rails and background agents as well.
So things you can launch and sort of leave or chat with on
your phone so you don't have to have your laptop even open to
code. That's the overview.
Interesting. Like there are so many new
technologies, so many new tools, so many new AI things coming out
at the moment. Like if there's something new
coming out next week, what would the workflow look like when it
comes to giving it to the people?
Like really making the most out of it?
Like do you have a top down approach or just engineers free
to choose whatever they want and you have a bottom up?
Like how does it? Look like, yeah, yeah.
So we found success in gauging sort of the popular interest and
then the vibes, if you could say I could, I could call them that
out on the interwebs. So you can imagine, you know, X
or Twitter sentiment, other companies adopting tools.
We tried to stay at the very forefront.
So if you have a big wave coming, coming on, there's
usually, you know, Hacker News articles, We've got a really
sort of plugged in team that's essentially forwards like new
like interesting lab leading lab posts immediately.
So you get like within an hour, you know, whether you know, Opus
4.6 drops or something, or if there's someone like Openclaw
releases. You also get like in the theme
channel itself, you get the the piece of news.
So you can read them. I read the news and like, oh,
you know, we need to get on this.
Or maybe this is, you know, overhead.
Do you have specific criteria on how to evaluate whether you want
to dig into a certain topic or not?
Yeah. That's a really good question.
We actually have, we sort of have this funnel, it's not fully
built, built out yet, but the idea is at the very top of the
funnel. You have sort of popular
sentiment and then you can look at, for example, benchmark
websites. So we have, you know, suite
bench. There's another one that's I
forget the name on of that do daily and weekly and monthly
tracking of different, you know, a genetic CL is X different
models that those CL is can run on.
And if you see, for example, a new offering, I don't know from
China, like deep sea popping up, you might want to validate
through public benchmarks. So they run a bunch of like bug
tasks against say the, the Linux repository or Chrome or
something. And then you get a good picture
and a good initial filter. So you can stop, you know, like
if if people say it kind of sucks, you cut it off there.
And then the bottom of the funnel gets into internal
benchmarking, which is you take, you know, sort of larger or, or
bloopers repos are large in scale.
So you take tasks from those repos specifically and they
also, you know, it, it's not an open source repository.
So we can't just like clone the repo and build it.
And so as an example, you know, you have a lot of companies
offering background agents now, but all of them depend on the
companies providing compute by themselves to the background
agent. So what happens then is we can't
actually leverage it because our repos are not hermetic.
They can't be built outside of Ubers and Fed that easily.
They can't test, can't run on a bunch of other problems.
So that just crosses out that whole class of agents, even
though on the open source side of things it they seems to be
working fine, you know, completing tasks and whatnot.
So that's the the sort of middle layer it's automated
benchmarking for on the internal side of things.
And now the third level would be just user like focus groups,
giving, you know, a set of power users, the tool, seeing what
they think. If the feedback is negative,
it's also likely that no one else will care.
Like, why do we even bother investing in this?
If the feedback is positive or very positive in the case of
some tools that we had recently, you get a, you know, you just
start pushing it. So like make it available to
people. And then perhaps if if the
adoption curve is is not steep enough, you can do workshops and
hack days and whatnot. Let's say people are really
actually using it. Do you have sort of KP is like
measuring developer productivity or the outcome of using those
tools and what what are these? Yeah, yeah.
So the classic OK R or sort of metric that is predominant or
used to be predominant is essentially diff count or code
change count. So or, you know, get that VR
count and there's various symmetrics, like how many of
your code changes are X size so that you don't have like a bunch
of small little nitpicky changes.
But to, to zoom back out, if you look at a group of engineers and
some of them are adopting a certain tool and that metric
goes up, you can say at least that they're producing more code
changes of, you know, certain size.
That's a good proxy metric for productivity.
It's not actually it, it's not connected to the end goal of the
company, which is shipping more features, improving the app, but
it's a proxy. And we've been trying to link,
there's some interesting work going on to actually link those
that that proxy metric to a more concrete like, hey, you know,
these features were shipped because of these code changes.
So then you can look at feature velocity and like essentially
map more towards like a actual gross booking value outcome as
opposed to just looking at, you know, discount and assuming that
it, it will result in better outcomes for the company.
So that's one. And then there's other angles
you can look at for just optimizing the engineer's time
spent developing and doing other tasks.
So things like tracking how much they spend on docs, you know,
are they like reading the meeting notes, for example.
This is goes a bit outside of coding as well, but do they
spend a lot of time in ticketing systems creating tickets?
Do we need to help them with that?
This is sort of really early that tracking is a complicated
system to set up, but we hope that it will enable us to even
spot bottlenecks that we didn't know existed before.
Like why is someone spending so much on, you know, this Google
doc or like AG ratio? I can imagine, you know, JIRA
being like a pinpoint for some people, but I, I know that
there's things that we don't even know that are bottlenecks
that they're trying, We're trying to.
Discover, can you walk us through like what maybe right
now the the workflow is for an engineer like how did you what
type of augmentation have you already implemented in the
developer experience when it comes to delivering features?
Yeah, so we have a lot of different tools.
I don't have a way to flash like a graphic of everything we have,
but you know, from the very beginning, like planning and
designing stages, you've got your, you know, E augmented
prototyping tools. We've got Figma but.
If you have a graphic, we could just put it into the episode
later on. That's what I'm always saying.
At least we're in the end. I'm already forgetting to put
it. Yeah, yeah, yeah.
Gotcha. I'll see if I can pull something
up. But anyway, for designing you've
got your figma, your lovable, whatever.
We we're have this new explosion of POC capability now to where
you can bring a whole quote UN quote working product or like a
demo of a product into a meeting as opposed to like a big idea or
like a SketchUp in Excalibur. So that's a very fun new
capability that's unlocked because the cost of them is so
low now with agenda coding assistance.
But yeah, so past the design stage, you've got, you've got AI
enabled ticketing systems now. So you've got linear, for
example, you can do instead of going through the web UI like
messing around with creating a ticket, you can do, you know, in
Slack at a linear, make a ticket for this item.
That's pretty cool. And then past the design stages,
when you get into actual coding, we have it, it depends on user
cohort. So the most we we have, you
know, power users and sort of more regular engineers or, or or
regular AI adapters for power users.
The predominant sort of pathway to develop now is agentics.
CL is so that it splinters into a few different offerings.
You've got clock code, you've got codecs, CLI and for the real
like massively parallel work streams.
The power users are able to paralyze those agents through
something like AT Max terminal manager to where you have, you
know, let's say like six of those agents working for you at
the same time. They've got notification set up.
So they notify you, the engineer when they're done so you can go
and switch back and continue work.
And yeah, and we are trying to enable engineers to just tell
their agents what to do. So like, hey, publish my change.
And then the agents themselves need to have the know how.
So whether it's be whether it be skills, throntropics, products
or commands, you know, cursor and whatnot to let's say create
the PR or the DIF so that the engineer doesn't have to spend
more time like making a description, calling the Clis to
do it. It's just done for them.
And if they queue up enough actions like hey, you know, make
the change, review it, produce a report of how you validated it,
maybe do the like an end to end manual test and then publish the
change. You can queue up, let's say an
hour and a half worth of actions to where now that whole session
is parallel and just running. It's like a teammate that's just
doing its work. If it gets stuck, it alerts you
and you could check on it and you know, it gets to essentially
an end state. So that's power users and
general AI adoption. I think so far we've seen cursor
and sort of a genetic IDs be a primary interface for those.
So and you can imagine VS Code plus any of your extensions
compiled or cloud code as an extension and VS Code is nice
cursor of course, a product as well that's AI enabled.
So you do your coding there. It's primarily single threaded
still. So you have your code view, you
can do your editing yourself and then you have a chat session.
You can have multiple chat sessions across multiple files
as well as well. But it's yeah.
And like orchestrating the multiple repository
implementation details is also a topic that more of the power
user cohort gets into and gets really resolved so that you can
do multiple issues on the same repository at the same time.
Meanwhile, the regular users kind of stick to a single repo
or maybe a couple clones. Yeah.
And then past that, we have at diff review or PR review time,
you have tooling to go over your diff and spot bugs.
So you we have our internal tool called you review.
We have cursor bug bot running, so spotting things that you
might have missed in your, you know, publishing steps.
And then that's it. Then you go to human review and
you line the code change. And then there's really quickly
final sort of side tangent that it's going to grow a lot in
adoption in the coming year or two.
And we're actually expected to become the primary means of
editing code and that is the background agents.
So you, instead of even creating your own development
environment, unless you're like the superpower user that knows,
essentially orchestrates the background agents already in
your background in your environment, like dev box.
You, you have AUI or you start to slack or something, you know,
add an agent and you start a task.
So like give it an issue or something and then it doesn't
work in the background for you. And then 40 minutes later you
get a notification for, Hey, I'm done.
And you can like zoom in, edit the code, follow up, give it
another hour of work to to go. And then if we, if you have a
nice interface for those, you can have like again, six to ten
of those agents running in parallel.
It really gets into more of the human, the limit of how many
parallel things you can think about at the same time because
you need to have this rolodex of ideas.
Now I'm working on this thing and now I'm working on something
else and just be able to do that to support this workflow.
But we're hoping that engineers will train that muscle because
to maximally lever up like we have this, the nascent concept
of like the parallel parallelization factor of an
engineer, how, how many work streams can you do at the same
time? So instead of just doing 1
synchronously like you used to do before, maybe it's not 2 or
perhaps probably it's three like a median.
I know some people can go up to 67810, whatever.
But it's, that's, it's really hard to even keep the agents
busy for that long because you're going to have to review
and think about what the problem is to even unblock those agents
first. So yeah, that's the overview
there. That's crazy, like 7-7 to 8.
What was it? Yeah, 78910 again, you have
these agentic sessions running. You need to have enough projects
under your scope to even give them that much work.
And they have to kind of all be separate.
You can say, hey, I'm going to make this feature that depends
on something like Agent 2 can't work on something that Agent 1
hasn't already finished. That's the problem.
So the, you know, Agent One will have to, but we'll be kind of
stuck in the like feature, a complex feature development flow
where it does the the one thing and then it'll have to do the
the follow up on that maybe in a different code change.
But again, if you are expanding into new verticals, trying new
features, you can just take up a completely new work stream.
It doesn't depend on anything previous and just have that be
your second agent. So 8910, yeah, ambitious.
You're probably doing not necessarily coding tasks at that
point. This is going to be like your
rewrite, you know, documentation updates or whatever else you're
trying to do to clean up your code base or migrations.
But yeah, certainly possible. It's just very small sort of
cohort that people so far can do it.
How does a roll out look like? Because I could imagine that not
each engineer is like always on the cutting edge of things and I
was keen to try out new stuff. Sometimes you want to just get
your work done. How does a roll out look like to
really get everyone on board? Yeah.
So and how do you overcome like when people are hesitant to try
new stuff? Yeah, yeah, yeah, for sure.
So the roll outs it it they largely follow the adoption
curve for various products. It's sort of a general concept
of you've got these early adopters that jump on the
product. If they know that it's good,
they usually are plugged in themselves.
So they, you know, follow like Twitter sentiment and whatever X
sentiment and they come to us to ask for the product, like, Hey,
when can I use this? So that's pretty good.
That's essentially autonomous, you know, adoption, what is it?
Organic adoption? And then once you get into that
board, we look at if the results are good, you look at posts.
Well, we, we do a multi channel reach out so you can do, you
know, you have Slack channels for informing engineers.
You have sort of show and tell sessions.
If, if the product is really starting to roll, we try to do,
you know, an hour of, hey, what's my workflow like?
You essentially invite the whole engineering force into that
whole meeting and have an engineer that's a power user
show off what they've been doing to inspire and sort of show
that, hey, it's easy to set up, you can do it.
And we see that a lot of people follow that as if it was
essentially a workshop because they're like, yeah, you know,
this looks good to me. I want to ship more features.
You know, productive workshops work well as well because
that's, again, the same form factor, just a little more
enforced than it in person. So it helps with, like, if you
have multiple offices, you set up a workshop for a specific
topic. I remember we had ones for
cursor, not for Copilot before that, and then for a Cloud code
after that. So, you know, whenever a new
product comes along and people are interested, you set up a
workshop and you do essentially the same thing.
It's like, hey, here's a demo, perhaps try to create a feature
or, you know, fix a bug or something through its workflow.
And then you have an sort of an interactive audience to present
your flow where someone can say, hey, you know, I'm having
issues. And then you just walk over, you
know, unblock them and and continue on.
So yeah. And then Slack announcements, as
I mentioned, you have enablement channels, so that and we have,
you know, emails and Slack sort of news channels that you that
people subscribe to. And then on top of that, I think
we also have sort of an engineer lead culture, which is quite
nice, where you have an engineer engineering lead, like engineer
post in one of those channels to like signal boost again, like,
hey, I stand behind this. I've I've checked this out.
So that helps bring credibility to the actual tool and help
people be more comfortable with using and trying it.
Yeah. Not every company has that Uber
engineering culture. Like do you have any tips and
tricks on how to like engage engineers from other fields,
from other companies, maybe larger organisations to really
keep up with all the new tools and new techniques that are
coming out? Yeah, yeah, yeah, for sure.
I think a really powerful tool is having ambassadors for any
sort of topic, not necessarily even in tech.
And because the, the, the person itself that's an ambassador is
likely to be motivated to, you know, show they, they believe in
whatever that they're an ambassador for.
And that really helps translate to the people that might not
know about the tool or that you, you know, might want to have
listened to to that reasoning there.
So, yeah, essentially singling out because every single
organization will have a more, a set of more like power users.
You know, it will depend, the distribution will vary, but
you'll have people that are like have everything set up and
perhaps, you know, in your org or the power users, someone that
just set up Claude code or maybe it's cursor.
That's OK because you can use their, you know, if there's
enthusiastic about the tool, you can leverage that to broadcast
out to a more broader audience again, by just like creating
perhaps a meeting show and tell. If it's a small enough company
you can also get by with physical sessions again where
you do a presentation to like the whole office or something
and just show off like hey this is pretty easy to set up.
I've got it working and it works a lot faster now than what I had
before. Yeah, that's the initial
thoughts. I, I wonder how you manage costs
at Uber because like with all the different tools, it might
get confusing. Like every tool has its certain
pricing models and all of that. And I I.
Think there's like a a? Tool life cycle where it gets
hyped, it gets used, but then there's another tool coming
along and you have a certain percentage of people like using
the old one and like growing percentage using the new one.
Like how do you manage costs with all your different tools
that you set up? Yeah, yeah, for sure.
The that is a real operational problem you have.
Well, you know the the companies that produce the tools have the
incentive to just give you a bunch of seats and keep charging
for them. There is a challenge in if
someone stops using a tool, how do you set up sort of proactive
seat pruning and whatever else you can do to like take away the
seat from the user, give it to someone else that maybe needs it
and that that's that's some work you might need to do for smaller
scale companies you can just get away with manually marking like
disabling users. I don't think there's a problem
with with that at all. The the key though, is if you
have some tools provide like adoption metrics and you can
see, you know, oh, you know, this user is using mostly
whatever cursor or clod you can make informed decisions about
the rest it I don't, I don't think based off of our stats
that a lot of people do multimodal synchronous code
editing. So like they, they will choose
for the back background editing, they might pick, you know, and
an interface. And for local synchronous flows,
they pick an interface. And we had cases before where
people, let's say from that prefer the Intellij ecosystem,
pick a, let's say, pick up cursor just because the AI
orchestrator is so good in cursor.
So this was like a year ago or something, but they still want
to have their main ID present. So this is kind of a bifurcated
flow. It's not suboptimal.
But then you have to pay for the two seats because again, people,
that's what they find most useful.
And we're trying to, you know, call us into a single more
unified workflow where you don't have to contact switch.
You've got your favorite orchestrator, A genetic
orchestrator available. But it will inevitably lead to
these overlaps. And yeah, so see pruning usage
metrics tools to expose that depends on where you get your
inference from. You'll see what who's using what
in terms of yeah token, sort of what was it the the.
If it's an outcome based outcome pricing.
Well, outcome based is, is we haven't really gotten into that
yet. The industry isn't yet asking
for prices or like a cut of every single code change or
something code line. I I think that that will be kind
of damage. I mean, good for the inference
company. I was trying to lean towards
whether you allow engineers to spend at infinitum essentially,
or whether you put a cap on their spend.
I think there's a strong case for letting them spend on
infinitum, but with perhaps what we found works as manual little
checkpoints like saying, Hey, you've spent X, you know,
dollars this month. Are you sure can?
Can your manager sign off? Are you like not running in a
circle, like just doing random crap?
Are you using it productively? If yes, go go right ahead.
You know, we'll support your usage.
So that's a nice little speed bump that doesn't stop the
engineer, but provides us a bit more or notifies the engineer of
like, hey, B Cognizant because they might be running things
that they don't even know are running in the background.
Interesting. Yeah.
For how long have you been doing this at Uber?
We so from the very initial, like I think Copilot was the
initial impetus of all of these coding assistants we had.
That's when we started, we enabled Copilot really quickly
and then we found that people, well, the initial Copilot wasn't
really that much that capable with GBD 3 or what was it?
Completions was one model codecs, but Chad was I think GPD
3 or 3.5. And we found that people didn't
really trust it yet. We had this big sort of hill to
climb of like people not wanting anything to do with AI code.
They're like, yeah, this is crappy.
But again, through outside influence or sort of the, the
overtone window shifting towards, Oh yeah, this might be
producing good quality code that has largely been resolved and
everyone's now on boarded. And we have like 95% of users
using some kind of AI tool to augment their development
workflow, which is nice. But yeah, the, the, the start, I
think we kind of jumped really early onto the Copilot train and
then we built like we had a big testing glut and we needed a
testing tool that was capable. Copilot wasn't able to provide
nowhere close to the amount of identity capability that we
needed. So we built out a custom product
built on a custom line graph graph with multiple sub agents
or sort of a mixture of experts before that became a really a,
a, a mainstream concept that's even built into the foundational
agentic systems. That it was like what, 2-3 years
ago? Yeah, yeah.
It was around the time of the Copilot initial release and.
Because where I was going with the questions, like I, I really
wanted to know what was the most surprising thing that came up
during that time? Like did you encounter any like
super surprising situation that you didn't anticipate?
I think. We, we just the, the, IT wasn't
so much as a surprise, but the realisation that the genetic
assistance back in the day, you must build them as a, a genetic
assistant provider in a way that makes them extreme generalists.
So you, you know, you, you have, we didn't even have command
execution back then. It was just code editing.
But even then you have this whole gamut of users across a
whole range of open source and closed source code bases, you
know, dozens of languages and you need to be able to operate
in all of them at the same time. We had this sort of like, hey,
we can build some really capable deterministically enhanced
flows. So you can imagine we actually
went that direction with Claude Code now having skills as an
example where you can plug in a script and the script actually
does some deterministic action for the agent and it's able to
like launch it and leverage it and then act on the result.
That direction we realized very early is would be moving forward
because again, for workflows become competent and especially
within like a larger scale company, you need to plug in
some deterministic flows. And that's what we were able to
do with the land graph graph that I was talking about.
So you can do like crazy, you know, you plug in your build
system, you can customize to for it to fit your build system
exactly. So we can do, you know, hundreds
of parallel builds at the same time as an example, instead of
A1 single command. And that's like claw can't even
do that today unless you build some skill.
I don't think it will likely ever, well, not ever.
I will not say that, but. Ever is a very strong word here.
Very strong. Word.
It's probably going to be able to.
Do it in a year. But what I'm trying to say is in
like cloud still runs, even if you do parallel agents, it still
runs same build, the same build commands.
You'll need to provide some skills for it to like understand
how to even like finagle your build system into running 100
different permutations of the same file to like try different
variants, stuff like that. So extreme agentic programming
is very custom and the bifurcation that I was trying to
explain to that we realized this, the generalist assistance
will not like automate this away like this will never happen.
We need to build this these foundational building blocks
that, you know, plug into our build system and know how to
operate at Uber. And that's what we're continuing
with. I think over time we found that
the agentic like the speed isn't that much of A bottleneck.
So the agentic generalist assistant is kind of good enough
for a lot of things, but it needs these tendrils.
It needs a tendril to reach into like the build system.
It needs a tendril to be able to understand how what conventions
we have with Uber or like search docs, stuff like that.
Being for it to like interface with what Uber is all about and
our engineering practices is very important.
But that surface area is again now plugged by things like
skills, which are easy to develop, you know, improve.
That's, that's that. The one question that what that
really interests me is like did the adaptation of agents and
agent coding change the way engineering teams are
structured? Like did you see a change in how
the team's structured, how the team is set up, how teams
behave, or like cross team initiatives get managed?
Yeah, that's a good question. So if we call back to earlier in
this conversation where I said you needed to expand the amount
of threads and features are parallel working, working on
parallel at the same time, this lends itself really nicely to
more efforts that are essentially more efforts between
more teams. So we got a bit more
connectivity. You've got people from a team
joining more virtual teams now, at least from what I observed,
meaning a virtual team is like, they're not part of a, a
different team, but they're part of an effort that's like outside
of their team potentially, but needs the involvement,
involvement of their team. So then what you get is someone
dedicates, let's say 10 or 20% of their time to a specific V
team. But in effect, their
contribution to that effort is now like 80 or 90% of what it
could have been if they went in like essentially full time on to
that whole effort, but before coding assistance.
So if you imagine like they can deliver with the leverage that
coding assistance offer, they can deliver like full time or
even more as we get into the, the more leveraged work streams,
you can deliver more that you could have before if you've like
full time joined that team. So that's awesome because again,
you, you have these like whatever amount of E teams you
can manage mentally and you're pushing everything forward
because it's really not you're working, you're managing a bunch
of agents. So you have you're like an
engineering tech lead, I guess that has his fingers and a bunch
of different efforts. But you've got these virtual,
you know, teammates that actually like the the agents
that deliver on those because someone needs to write the code
and validate the code ultimately.
So that that's the sort of impact on the organization that
we see so far. Before we close the episode, I'm
really curious if if you have any tips and tricks for our
listeners to really stay at the edge of tech and do not miss out
on any opportunities on new things that are coming up.
Like, what does your workflow look like when it comes to
really being at the forefront of what is coming out?
Yeah, yeah, for sure. So I personally have I, I, I'm a
avid believer in the personal assistant space that's sort of
popping up right this moment. So you've got open claw or nano
claw or whatever else. It's non trivial to set it up in
a secure way. So I will not recommend any
anyone to do it because if you give it access to your whole
laptop, there's a lot of implications that you.
Don't want. Don't, don't, don't.
Want to do that? No, no, don't do that because
the Mac mini is already expensive enough.
Don't. Well.
So yeah, yeah, you either have to like completely separate it
out, run it on a VPSI know companies are now coming up
with, you know, isolated environments to run these steps.
Yeah. But then do you, do you have the
data on the machine that it takes to really get good
results? Well, well.
The good thing is you can have it like be a super consumer of
public streams. So things like let's say you
have whatever the amount of RSS feeds, 50 RSS feeds you're
interested in, kinda like Hacker News.
That's essentially you don't need the login session for that.
You don't need anything for that.
If you just run it on like AVPS that's not connected to any of
your data at all, it will be able to fetch those sort of
surface level things. All of the labs just give it let
it research what to research. That's sort of a meta level
thing. It's like find all the top labs,
you know, whatever the, you know, open AI anthropic Gemini
and look at that matrix of things like let it run, let's
say every morning or something if you want to be really plugged
in and let let it like send you a report over whatever the
interface you have. And that's a really good way I
found because it can also like you would need to set up like
tokens and API tokens for let's say Twitter analysis, like
popular sentiment analysis. But you could do that.
And then you have this whole like the whole thing that I
mentioned that started the episode.
It's like all vibes and you sort of yeah, like vibe based
understanding. You get that in report form in
the morning, which is really powerful and you can take what
you want from it. You usually get all the news
like the hour delta in that report.
So I always see them. I never see anything missed
because the report is kind of large based on the amount of
things that I added to for it to check out.
But yeah, that's probably the top thing that I found.
It's like the most helpful. Otherwise, you just make a list
and you go like once per week, like hack your news, whatever
Google Scholar papers pop up at the time that are important to
read. Yeah.
Thank you so much for coming to the episode.
I learned a metric shit ton. It was really interesting.
I was really glad you're here. Thank you so much.
And yeah, let's talk to you. Talk again very soon.
Thank you so much for having me. Thanks everyone for making it to
the end of this episode. I hope you enjoyed the
conversation with Amachas as much as I did.
If you're digging the podcast, do me a huge favour.
Hit the subscribe button, drop a like and if you're feeling extra
generous, leave a revenue. It really helps us get these
conversations in front of more. People.
We got some amazing guests lined up so you definitely don't want
to miss what's coming next. So then see you soon.
Bye.