# Local-First AI Agents and the Death of Apps

**Podcast:** The InfoQ Podcast
**Published:** 2026-10-19

## Transcript

How much authority should an AI agent have?
At QCon AI New York, learn how senior practitioners set permissions and evaluate agents in production.
Use their experience to decide whether your own agents need boundaries and checks before release.
Join us December 15th and 16th, 2026 at the Western Jersey City, Newport.
Explore the program at newyork.qcon.ai.
Hello, everybody.
I'm Olympi Pop, and I have in front of me Rachel Lee Neighbors.
They are quite a creative person.
They did a bunch of comics, I think, right?
And also they were involved with React and React Native frameworks.
And because I don't know how to put it in a better light, Rachel Lee, can you please introduce yourself?
Thank you so much for the introduction.
Yeah, you may remember me from my pandemic babies.
the React.dev and ReactNative.dev portals.
I worked on the React team for the pandemic.
I've worked for Fang on browsers for many years and with the W3C on web standards.
But before all of that, I used to make comic books for teenage girls.
I was one of the first web cartoonists that had their own personal website and mailing list, etc.
So I take my inspiration from Japanese comics and anime to this day.
You can still find me illustrating my own slides and creating mascots for the different open source projects I work on.
Nice.
Thank you for the idea, for the input so far.
So probably my kids will read some of the comics.
Today we're going to talk about another endeavor that you have, and that's local...
I don't know, aggregator, it would be probably the best interface for the social networks that we use.
Oh, yeah.
I used to be really big on developer advocacy.
You know, when I moved to London, I was a developer experience consultant for lots of startups and AI in the Bay Area.
But I've always wanted to get back into engineering.
And finally, I found a project that inspired me to return.
to building again.
And it's Mima.
That's M-I-M-A.
You can find it at Mima.social.
It is the client I've always wanted for managing all of my social and news connections.
Like, I don't know about you, but you can't do business in tech without being on X and LinkedIn.
And probably also Blue Sky and Mastodon, depending on where your friends are.
If you've got friends in Data, you probably need to be on Blue Sky.
If you've got friends in Open Source, you've got to be on Mastodon.
I don't have time to check all of those different apps every day.
And every one of them is like, oh my God, you've got to spend all your time here on X.
What are you doing posting links to other websites?
How dare you?
They are very protective of their little circles, their bubbles.
problem is you stay in one of those bubbles, you only hear from people in that bubble.
If you only listen to X, you'd think that everyone's using coding agents, but there are so many grads coming out these days that they've never touched Claude for coding.
So there's a whole world that you don't experience.
I built this to make it possible for me to exist and to see things coming in from any social network I wanted to connect to.
So I can repost something from X to Blue Sky.
It forms a local graph of all of my social connections, everything I've been saying.
And it uses native web APIs under the hood.
So there's nothing particularly magical happening there.
It's the browser I always wanted because for me, all of the big leaps I've made forward in my life in terms of career, understanding, etc., they all came through these social networks.
But over the years, social networks have become harder and harder to access from outside the bubbles.
So I started building Mima to solve my own problem, which was I just wanted to see what everyone was saying in one place and be able to reply from one place.
It's turned into its own little local app.
It's got little local models on it to make the experience better.
It's all privacy first and local first, which was kind of on purpose, kind of by accident.
The truth is, I just don't want to have servers with your personal information on it.
The last thing I want is to have various countries coming and being like, hey, we need all the DMs from user XYZ.
And me being like, what?
Oh, no.
So I have no interest in owning other people's information.
So that's how it ended up starting.
And yeah, I'm actually going to be in San Francisco doing a little pop-up soft launch for MIMA next week.
It's really exciting.
Okay, good luck with that.
We are just curious about the technical leaders because you mentioned that you are part of the...
React Crew and did a bunch of stuff.
So I'm curious about what were the choices you've made while building it?
Because you did mention also models and rather than having an L in front of the large language model, you have an S.
So guide us through the decisions, the technical decision you've made.
I have been following along with the evolution of LLMs since like GPT-3.
One of the things I've noticed, especially in hackathon scenes, because, you know, developer experience consulting is like my bread and butter.
So I go to a lot of hackathons.
I see what people are building.
And I noticed, you know, a lot of what people started to build as soon as LLMs became, you know, API accessible was a wrapper.
It's an app that takes everything the user gives it, sends it over to someone else's server somewhere.
where they do God knows what with that information, probably train your competitor's model, and then they send you back a response.
First, this is incredibly wasteful.
I did a series of articles on web.dev with Google about right-sizing the model and a lot of research on the cost, the energy cost of running inference on a multimodal model.
It's like...
four times higher than necessary to do most of the work that you could do with it.
So it's energy intensive.
That means that cost gets passed to you in terms of the API costs.
Now you've got linear costs going up with every time you call that.
And also it brings in all these wonderful privacy concerns.
You know, is that PII?
We've had so many instances of private personal information showing up in public because somebody sent a prompt to a model.
And it got passed onto a search engine.
So there are reasons why you don't want to just round trip with a big inference.
Luckily for us, the technology has moved forward so fast, so well, that small language models now do pretty much...
All the same things that people were trying to send off to big inference back in the day.
Small models are perfectly fine for summarizing things.
We've got JEV, which is great for picking the right tool or offering a simple yes or no.
JEV just completely blows the lid off of everything.
So there's a lot we can do with a little model that we don't need to round trip to Gemini or to Claude to get done.
And I think it's the first thing we reach for.
You know, the idea is like, can we prove that it can be done with a big model?
That's fine.
But you probably don't need to be shipping to production the round trip or the high API costs that you are.
Kim, thank you.
So you have multiple models in Mima or you have one that has multiple hats?
Well, that is a great question.
What's the right model for the job?
Mima does have multiple different little models inside her.
The one that I got started with was Llama 3.2b.
I was using Claude Sonnet to summarize, for instance, conversation threads when I first started building her.
But very quickly, I started feeling uncomfortable with sending my private messages to Claude.
So I actually set up some evals, and with post-processing, I was able to get Llama 3.2b.
to perform as well as Claude Sonnet at summarizing locally the conversations that I was having.
Evals are really your best friend here.
They let you actually rate and judge the inputs and outputs.
Like if I had just listened to my friends, I would have chosen Gemma 4 because Gemma 4 was really hot right then.
But it turns out Gemma 4 would have actually substantially increased the latency on these summarizations, and it wouldn't have provided as good summarizations as Lama 3.2b did.
So I used Phoenix, which is a little evals library that you can set up there to run tests against real information, and used a large model as a judge to pick the best model.
that could do the job.
It turned out, of course, it was LAMA 3.2b, which is one of Facebook's models that they've trained on user data.
So it makes sense that it would be good at summarizing conversations between humans.
However, that model might not be the best at doing things like identifying when people are being toxic or if...
images, for instance, contain alarming things in them.
I'm a big believer that our clients should be able to moderate for us rather than relying on the platform to do that because platform owners, you know, Facebook, LinkedIn, etc., they always don't really invest in moderation.
It's a cost center for them, so they cheap out on it.
And that means that it's sort of lower the flies.
The kids are running the schoolroom in there.
So it's better if your client can do things like, oh, this is an incoming message from somebody this person doesn't follow.
I'm going to check to see if it's abusive content.
You know, you post a picture one night, you wake up, there's 40 comments on it.
How many of them are, that's a great picture, versus how many of them are like, oh, how dare you take this picture of a dog?
And you never know.
But the idea is that you can use models that are...
specifically trained to check for different kinds of things to help you write better or to check to see if incoming content is abusive or unfriendly.
And Mima is mostly geared around moderation right now, you know, making sure your trigger warnings aren't being tripped up, etc.
And for that, summarization is not necessarily the best option.
There are smaller, lighter models that can do a better job of that.
And all of them are opt-in.
If a person turns on a feature that needs another little model, you know, they have the option to turn that on, download an additional model.
It's never installed by default.
I think this is something that companies who should know better, who have a lot of experience building products for humans, have missed from back in the day when, you know, 15 years ago, we were all reinventing the wheel and learning how to build apps.
progressively enhance the user experience.
There is this idea that the user should be able to opt in to enhance their experience.
But if it's going to cost extra, you know, extra storage space, etc., you need to ask their permission.
And of course, you could always offer them a cloud solution as well.
But for the reasons I already stated, I'm not really providing one of those at this time.
It's not like, well, would you like me to process all of your incoming tweets on my servers?
Or would you like to download this model?
You could do that.
But for me, it's just going to be, would you like to download the model?
That sounds closer to home.
And also, I like the fact that the information doesn't leave your machine.
So that's quite useful from my perspective and probably others as well.
And the moderation.
It's highly important.
It is.
I think one of the things we're going to see happening with AI assistants and personal agents in the near future is we've been building them thinking about like, you know, HubSpot integrations and how to do business with them so far.
But once they hit the consumer market, they're missing something important, which is your personal context.
Yeah, you can connect them to your email, but how are you going to connect them to your LinkedIn to help you find your next job?
How are you going to connect them to your Facebook to keep up with the kids?
How are you going to connect them to all of these wild gardens out there, each one of which wants to keep your data in their databases?
And remember that the power of that data is only really unlocked when it's cross-contaminated, which is a huge security risk, I know.
But there's also so much to be said for if we could just have access to the graph, you know, our own social graph across multiple different networks, our own posts across multiple different databases, our personal agents would become much more powerful for having that context.
Not even necessarily to post, but they would just know more about us and be better able to help us as individuals.
Well, I like that you're looking only at the positive part and I'm all in supporting that.
You did mention evals and that tweaking your model for that particular use case, it gives you the option of having the same output as a large language model.
Well, outcome, I think it's more appropriate.
Maybe a couple of hints on that, especially given that...
You discussed about something that doesn't have a deterministic form.
You spoke about text summarization, right?
That's a bit polymorphic.
Probably a summary for you to be different than a summary for me.
How did you attack that problem?
What would be the tips that you can give me if I intend to do something similar?
So I am a big fan of Hamal Hussain.
I don't know if you're familiar with his work, but he is like a demigod of evil.
evals, evals, evals.
And I come from test-driven development background.
But when I saw evals, I was like, oh, this is test-driven development, but for AI.
Got it.
And Hamal is a big proponent that you don't just put together an eval and, you know, say, hey, Claude, which one of these outputs is better?
Hamal is a big proponent of You walk through each one of the sets, you know.
So the idea is you take a couple of threads from whatever your source is.
In my case, we'll say it's X and maybe some LinkedIn threads.
And I know what the threads say because they're mine and I have an opinion.
They're real.
First off, they're real threads with real people.
They're not fake.
They're not something that Claude generated to hypothetically summarize.
First, you get them together.
I know what they're going to say.
I have an idea of what the output is.
Note that down somewhere.
Note down what I think the summary should be.
And then you run those through really big models.
You get your Astra to summarize them.
You get your Claude Opus 5.5 to summarize them.
And you see, yeah, those look about right.
Those are good.
That's the bar, right?
You're also recording.
other metrics like latency and making sure that it's actually able to output the right format for whatever it is you're using at the time.
Now, the next step is now that you've prototyped big, you want to start with the tiniest model you possibly can and a couple of others.
In this case, the tiniest I had was like, oh, it was like Quinn three point something or other itty bitty.
Quinn is really bad at this.
And I was like, all right.
We'll see.
We'll see, y'all.
But Quen was also really fast for being terrible at the job.
So, you know, you line them up in a row.
You get your Quen, you get your Gemma, you get your Llama 3.2b.
You know, you're going to have to do a little research to pick the ones that seem like they are, you know, top of the line for you.
And you run an eval suite with all of them.
And you run it multiple times over the same thing.
Because it's non-deterministic, you'll get different summaries each time you run it.
So usually like three times.
with a model and an input coupling will give you a couple of things.
What you do then is you actually go through and you can read it yourself and be like, yeah, that summary is about right.
No, that's not right.
You get to actually judge them yourself or you could just say, hey, Astra and throw out your keys.
I want you to see if this lines up with what you expected as a summary.
That's the faster way.
But I think Kamal would be like, no, you need to judge them for yourself first and go through those steps.
But then once you have it set up, you can actually go and you can compare like on a metric.
How many times did it pick out the different topics that were brought up in that thread?
Did it sense all three topics?
Did you count all three topics that were there?
Was it able to point to the place in the conversation where each topic was brought up?
How long did it take?
And it's usually on an accuracy and speed.
You're making a trade in one direction or the other.
And you will get to make the decision how important it is for things to be accurate or fast.
But that's how it is.
Once you set that up, you start building your golden data set.
In this case, I add fuzzed conversations to this data set to start looking for things like, you know, if I wanted to build a toxicity detector using Lama 3.2b, I'd have a golden data set of mean things people have said to me and others on Twitter.
Not that I have that, not that I'm actually using things that people have said to me on Twitter to test models, catching mean things people say.
But you build this golden data set, it becomes a part of your traditional CI, CD runs, and that is how you move forward.
Now, when there's a new model that comes out, just really balling and you're like, oh my God.
Is Gemma 5 it?
Is it going to be faster, better, etc.?
Now you just pop that sucker into your evals and you can decide for yourself.
It'll show up on that speed versus accuracy binary and you can decide whether you're ready to swap in a new model or if you want to stick it out with the old one or you need to make some changes to your prompts or input preprocessing.
To summarize, your answer is it depends, right?
Like all proper engineers.
Leaving joking aside, you choose your poison and see what's more important.
Because you mentioned local first, if you push on that, one of the points of the local first idea is don't have any spinners.
If having the fast things and accurate things, then you can probably have a balance and choose the right spots for you.
And then once you have a golden set, then you can move on with that.
Interesting thing, surprising stuff.
You mentioned no spinners for local first.
And this is one of those surprising things.
I didn't realize that even though the model is running locally, it can be slower than a round trip to a model out there.
Gemma, for instance, Gemma 4B, running locally on a pretty beefy Mac, that's another thing.
The metal that's available on the device might mean it's slower.
An older machine isn't going to do as well running a local model.
as like something with an M5 chip.
So keep that in mind.
But I thought local first would mean low latency, hands down.
It was not true.
Smaller models can take longer than foreign ones to do the same amount of work because they're underpowered.
It's like the difference between having like a jet engine and like a little two-stroke scooter engine over there.
Yeah, you can power one from the gas station.
That doesn't mean it's going to take you there faster.
Well, and probably that is the other thing that just thinking about it can be problematic when running local first is that you don't have always the same setup.
If on the same machine, things are happening a bit differently.
I don't know.
You are not running on a Mac, you're running on a Windows machine and you forgot to restart it in the morning.
The user experience will be probably degraded or even if the data started gathering because I would expect that putting data locally, the metadata that comes with all the social networks to be challenging to take care of.
And then probably also the, I suppose you will have something locally like a database.
And on top of this, a small language model, you have a database that you're querying.
And if that increases, so it depends that you have to respond to.
There are.
I have a feeling eventually Mima is going to be one of those things where you can buy the cloud solution and you get a VM somewhere that's running an operating system and it has infinite space to grow your database.
I have a feeling that would one day be the solution.
But for now, getting it to run locally on a big beefy Mac, my initial consumer is, I assume, is a person like me who has a modern MacBook Pro, etc.
The testing.
for making sure that local models perform well really requires you to know your audience.
You know, if you have existing data, this is why it's much better if you're working with an existing project than if you're building one from scratch, like some people I know, is that you have all this user data.
What is it that people are using?
You could then ship local models to folks that you know are going to have a more capable machine for handling that, you know, the latest.
operating system that requires a certain chipset to run is a pretty good indicator, for instance.
And you can also do a little bit of detection to see if they've got the right amount of horsepower to run the model.
And if they don't, you can fall back to a cloud provider in that instance.
Another thing.
Just because your local model, your small model, can't be run locally doesn't mean that it can't be run in the cloud.
You still can pay incredibly just the hosting costs on an open source small language model in the cloud.
It's still going to be much cheaper to run than, you know, running up your chat GPT or your cloud API bills.
So keep in mind, just because it can't run locally on the machine doesn't mean it can't be run cheaply in the cloud.
Just thinking about, well, this particular case, how much of your archiving data do you actually need in the real time?
Because as you mentioned, the way the scenario that you're using is what you usually do, what your friends did, what happened in the news, scrolling through it, finding ideas.
current day minus x and pretty much that's it.
So I am trying to solve a similar problem and then that's what we realized that actually 30 days of data is more than enough.
And rather than using a beefy database, we can go with something small.
In our case, it's .db.
Use that.
And after that, just offload everything in parquet files, do them calendar sharding.
And yes, at the given point of time, you actually can go with cheap solutions for S3 buckets in the cloud.
And when needed, you'll just go on that point.
And surprisingly enough, another idea that just popped while listening to you is the degrading aspect of a system.
That comes mostly from the distributed parts, so from microservices, if something is done, I don't know, just for the sake of it.
Spotify, maybe the search is not working now because that microservice behind the clouds is down now.
Well, that's something that we can understand also.
If we treasure our local first data, there are a couple of important decisions that we have to make.
Okay, I want to have it locally.
And that means that some things will work slower or faster, depending on what they have.
And I think it's quite, quite important.
I had a debate a couple of years back.
When the green software came to being and everybody was discussing about how important it is to adapt and so on and so forth.
And what I was challenging at that point is the fact that at points as consumers, not as engineers, we behave chaotically than when thinking about something.
For instance, a lot of the friends around me are listening to music while coding on YouTube.
And the thing is, it's in a different tab.
But that's still streaming 4K video that is very expensive.
And because on my machine, it's very cheap to decode it, it doesn't bother me.
But actually behind the scenes, wherever that coal is being burned or because that's most of the cases, I was surprised to hear that in Virginia, most of the electricity was produced through coal burning and the force of fuel.
It's actually a problem.
So bring in the problem.
on our machines.
And as you mentioned, also the target audience are probably engineers that are more accustomed and hopefully they'll understand it.
The target audience is for now.
We're always the first ones to adopt new things, but I truly believe more efficient on-device AI is coming for everybody.
And I love what you said about how it brings the challenges of like, oh, I don't want to use this one because it drains my battery.
There, that helps humans make better decisions.
That is localizing the cost right onto their machine.
But you could also say as a business owner, you're externalizing the cost of running the inference and running the algorithms onto someone else's device.
That's not your cost anymore.
And personally, I love edge computing, like literally on the user's device, because it really shows where economizations need to be made.
And you were talking about what do you do with really old information?
Well, Mima is a new project, so we haven't necessarily crossed those bridges yet.
But every 30 days, it's just, you know, content older than 30 days is released into the wild.
It's goodbye.
It's garbage collected.
Yeah, green pastures.
But you do need some persistent memory about the user.
I remember when I first had the idea for Mima, I thought I was building an agent.
And a friend of mine, Christoph Henkelmann in Germany, who's a PhD.
And he was like, no, you don't need an agent for that.
You don't need that.
You don't.
You just need this common algorithm, that common algorithm.
So I'm basically designing a database with an interface on top of it.
And he's like, yeah.
And it's true.
It's true.
Most everything in this world is just a database with an API and a UI layer.
And agents themselves usually boil down to...
It's a database with some non-deterministic LLM accessing it to reformat its contents for a human.
And once you see that, you can't really unsee it.
So the persistent layer is really just there for remembering the human's preferences and their relationships with the people around them, which can be really nicely distilled down.
Like, you can keep that information very tightly packed in text files.
So that's the part that actually does need to be retained.
What's this person's relationship with this other person?
Which articles do they like to read over and over?
But it's not too hard to store that locally.
I like how you put it.
So it's more or less energy.
So it's like content that we digest.
And the rest of it is junk.
And it needs to be flushed down the sinkhole or whatever.
Yeah, that's quite good.
And that evolves.
Well, these days context means something else.
The metadata for particular users, you store it, you have it, and that's it.
But again, that's a problem for a different moment.
The challenge of having things locally, it means that you might lose it.
So probably that's something that you'd like to have in the cloud or something like that.
But that's a whole different local first conversation.
I think it's kind of like keeping old magazines.
There's some people who are going to keep every magazine and every newspaper they get.
They won't let them go.
But most of us could probably recycle them every month.
Yeah, agree.
But this opens the door to a different question.
How will apps look in the future?
Because now we have the ability with models leaving aside the S or the DL up front, have the ability of just building something for you.
Now we have the ability to just...
give everybody the chance of building the app that they wanted.
There is an ongoing debate, build, buy, vibe these days.
Build, buy, vibe, love it.
It's something that we have to bear in mind.
So you did mention that you were part of those teams that put together probably some of the most important frameworks for building web and even local applications.
How do you see it?
Will the future still have frameworks, applications, web, mobile, whatever you want in the normal sense, or will just have meshes?
This is probably the most important part of the conversation we're going to have here.
And it may sound crazy.
Some of your audience members, they might think that can never happen.
I have often felt that way myself and I've watched it happen.
Well, we've seen more apps released in the last year than ever before.
But app consumption hasn't gone up.
In fact, people typically don't adopt new apps.
Like their core apps that they're using are apps they installed four years ago.
Apps are not growing.
Websites.
What are websites used for nowadays?
They are used as landing pages to download apps, and they are used for dashboards for B2B companies that don't want to build and manage a bunch of apps.
They're the lowest common denominator for doing business.
How will...
Apps be influenced by personal agents when they come around, and they will.
Personal agents are the app that kills all software for consumption.
When it comes to consuming content, buying things, it will most likely come through an operating system level agent.
That's because any operating system owner, you know, your Googles, your Microsofts, even Apple.
will want to and benefit by completely owning your interface with the rest of the world.
This has been at the core of Microsoft's battle with browsers over the years, and it is continuing to become the core of now Google's investment in Gemini and AI assistance.
big vendor wants to own your experience.
This is why Amazon sued Comet.
Well, they sued perplexity for their agentic browser Comet that allowed people to place orders.
They didn't want to give up that surface area because that surface area is ads, that surface area is upsells to their credit card.
That surface area is the one place where they can get you and have them just being boiled down to a set of APIs.
That a UI calls where they're just like a price point where someone's making a choice on where is the best place to get cheap beer?
That's bad for their bottom line.
They don't want that.
So it will be an ugly fight, but it will ultimately be an impossible to win fight.
We already see this.
People...
using Claude to do their searches for them, just looking at the AI summaries on Google search.
They don't care.
They don't want to visit your website.
They don't want to download your app.
They never wanted to do those things.
They just needed an answer or a thing.
They needed to snap their fingers and have it done.
That's all we've been building for.
So that's what the future for that looks like.
And if you are curious about like, well, how are they going to generate all the interfaces for all this information?
check out things like A2UI.
This is a standard by which your API can send the AI assistant a JSON schema of what information you're going to give them.
And that assistant can look at it and use its design system to...
make in a widget on the fly that meets that schema's needs.
It needs an image, needs a next button, it needs price, you know.
Yeah, yeah.
And just stitch that together using components, using components that react.
Did such a great job of normalizing.
And part of that's possible because so much work was done to create sort of this componentized ecosystem where you can just zip UI together on the fly.
And we can trust language models to do that right now.
to a good extent.
Notice I said something there, that something's been standardized.
When things are standardized, that's when it's possible for an agent to come and make things possible.
Stocks are standardized, you know, like the symbol, you know, whether it's going up or down.
These are things we've all agreed on.
There's an agreed upon way to represent them.
There's an agreed upon set of information you need to work with them.
That's the standard information concept.
Now think about things like your software as a service, your QuickBooks, your Shopify's, you know, these are the dashboard screens that people work with Salesforce.
The problem with these is that sure, anybody can vibe code a dashboard and, you know, a bunch of data structures and databases underneath, you know, you can create your own in-house Salesforce.
Yeah.
You're not going to be able to hire anybody who's going to know how to use it immediately.
You're not going to be able to use it with any colleagues or vendors at other companies.
You're not going to be able to be like, oh, yeah, let's team up together and share our user bases.
No, because you're now using, you're off-roading.
You've built your own standards.
You've built your own data shapes.
You're using a whole other set of information, and it is not going to be able to work with anything else, which makes it less powerful.
One of the reasons QuickBooks is powerful is because every accountant can sign in and use QuickBooks to help you with your mess.
And of course, you could say, well, can't agents do that?
Not quite yet.
There's still a lot of stuff that needs humans.
Humans still need to lay hands on things.
And often the most important human that can lay hands on things isn't in your company yet.
And so that is where I think the investment in open source protocols, open source standards, how much people invest in them will dictate how much of this can be vibed or handled via an agentic interface.
If you're like, oh yeah, our company uses the open accounting protocol too, it'll be much easier for your corporate agent and your accountant agent to do business with each other if they both speak the same language.
So that's how I see this evolving on a...
B2C level and the B2B level.
B2C, we're all going to be reduced to APIs.
APIs and the databases that we own.
You know, competition is going to be on fulfillment on the other end of those APIs.
B2B, the interoperability layer is the moat right now.
It's the moat.
Yeah, so standards are important.
Usually standards are...
brought behind companies and that put an acronym on it and then that's it.
Yeah.
Well, obviously, if a standard is not good, it's just about time for having another standard that replaces so on and so forth.
So we know that.
But the question is, we as consumers, what should we transform ourselves into?
Because we all saw something on a dashboard that looked good, but we don't have the proper naming.
So probably, as you mentioned, a ubiquitous language.
of different things for different perspectives, it would be quite useful.
Maybe the right question is, how are we preparing for this kind of future?
What are the tools it will be useful to have tomorrow?
I think the era of the bootcamp is justifiably at an end.
I think it'll be very easy to kind of like, hey, join our bootcamp and you can learn how to chat GPT apps.
But very quickly, people will learn.
There is no future in becoming a developer, in a person who can just create things, because anyone can create things.
You don't need to go to school for that.
You need to watch 30 minutes of a YouTube video.
Question is, how do you build things at scale?
How do you build things that don't turn to crap as soon as they go out into the road?
The complexity of the things that we are able to build now is now also infinite.
So, no one on the React team fully understood how React was built by the time I got there.
It had been through multiple key maintainers and revisions, and each member was an expert in a different part of it, but openly admitted, I don't think I know how the entire thing works.
We now have systems that can not only understand how the entire thing works, but they can make something five times as complex before the weekend.
How is a human supposed to build with that?
This is where I think computer science core fundamentals, really understanding databases, for instance.
This is something I spent a lot of time on early in my career, and I heard from many developers, you don't need to study data structures.
You don't need to understand databases that much.
You're just working in UI, right?
And I was like, but it's interesting, and I want to learn more about it.
That's the attitude you need to have, because the conversations you're going to have with agents are going to be about making trades.
They're going to be about the complexity of the system and reducing the complexity and building the longevity and understanding how you're going to change the rails while you're crashing down through the mountain on the engine itself.
Those aren't things that you really can learn without years and years of experience these days.
The trick is going to be learning those things early in our careers, which will probably happen.
because of many hard knocks working in the system.
But I think refocusing from just make UI by hand or, you know, a to-do app, refocusing from the more grunt work and into the more theoretical work, I think will be the first step.
And learning how to work alongside the agent as a collaborator, as opposed to just asking it for output and turning around.
We do see that happening with young folks these days, too.
You know, they're just adding vibe slop PRs and, you know, failing reviews.
The real trick isn't so much as just pumping out PRs.
The trick is pumping out PRs that ratchet up their quality with time and building the systems that can do that.
And that requires thinking.
Having a good understanding of computer science, but also having an understanding of machine learning and LLMs and how they're actually working under the hood.
They're not magic black boxes, they're math.
Once you understand how they're working, you can go, oh, you know what?
If we just sawed off the top of this Jeff model, we could completely replace that model over there and that would reduce the latency.
That's the kind of conversation that needs to happen now.
So a return to basics, a return to the well.
It's exactly against the obvious things happening these days.
Everybody considers that we don't need to know.
Well, that was true also when the internet appeared.
You don't have to know everything because you have access to it.
But if you don't know what to look for, what to search for, it's impossible.
And this is more on the social skills side, softer side.
It's probably critical thinking, curiosity, continuous learning, and then the social ability of interacting.
whether with a human, with a fellow human, or with a fellow agent, to be able to continuously move forward.
Agreed.
And one of the biggest challenges is that people think their agents know everything and they don't.
There are new standards and new technologies being released all the time that your model hasn't been trained on.
You are the wetware that gets to go out there, talk to other people who are building big things, come back and be like, all right, I got an idea.
Let's try.
This spec, this format, this thing.
That's your job.
You're the busy bee pollinating in the garden.
We've come from an engineering culture that made heroes of the code machine who could disappear into a room and just pump out perfect PR after perfect PR.
And we would tear each other apart in code reviews.
And it put a lot of emphasis on being perfect and being right because you only get one chance.
And if you're not, then you're dragging the team back.
We're moving to a place where code's free.
Part of it's going to be wrong.
The real question is, are you able to reason about it?
Are you able to ratchet up the quality?
Are you able to build systems that are flexible enough to pivot and weave with what the users need?
And that is a more collaborative space and less of an antagonistic space moving forward.
And I think those collaborative skills, as you said, are going to be real assets.
We spend a lot of time into the mechanics of things.
For instance, both of us mentioned that we are...
traveling in the upcoming period, I was just thinking about being in a car driving.
And then obviously the comfort of a car is important.
But if you'd be able to teleport like in Star Trek, it would be more important.
Why are we going there?
What would be the things on the other side?
And that's my feeling.
We as an industry, we are not as old as other industries.
We are just having a couple of decades.
But we did spend a lot of time into, we call it craft, but it was more like crap of how we build stuff and we just focus on the mechanics of how to build the things.
Now we can look at the social aspect of that point.
Why are we building it?
How are we building it as a group and the outcome that we have?
And I think that's important.
Another idea that was flying and I had a couple of conversations on it, the easy technology problems are done.
As you mentioned.
how to do the buttons and so on and so forth.
It's so easy to make the things.
Now it's important why are we doing it and all the important things that actually would help us as wetware on this planet.
I got to be honest, I hear a lot about people building these software factories and I feel like agents are really good at building stuff that's been built before.
If you just want to build something like...
Netflix, but for dogs.
You know, an agent's going to be able to build that without a lot of human input.
If you're trying to build something that hasn't been built before, maybe because it wasn't possible previously, or maybe it's because it just wasn't worth anyone's time previously.
Maybe you want to build a browser that brings all of your social networks into one really great interface.
Now's a good time to look at that, but you're going to have to put your hands on the code.
You're going to actually be working with an agent.
You're going to be having conversations and making trades.
You're going to need to know your databases.
You're going to need to know different kinds of, for instance, encryption formats.
So the exciting stuff is probably not building another fitness app.
It's probably that one crazy idea you never thought you could have time to work on.
And it's worth looking at now.
One of the other demigods of the AI you did mention.
And that was in line with what I tried and what to believe.
The AI can provide that extra 20, 30, 40% of your IQ if you decide to use it.
Because you can just say, do that for me and that's it.
And you're happy with what you got.
Or you can just say, okay, teach me what you did.
Wax on, wax off, as somebody would say.
And that's the important thing.
For me, what it means in all the doors that were open and probably for most of the people around me is we now don't have the need of doing a lot of research.
Because previously, as you mentioned, we have tons of databases.
Which one would you pick?
You have to understand it, do your research, understand.
And then if you go down the rabbit hole, you're gone and you're just debating that.
And you forget about the purpose.
But now you don't have any reason of not to have it because you have all the points that you actually need.
It's just about what you're trying to do.
As you mentioned, it's easy to do a lot of stuff.
Now it's about having them.
It's true.
It's a conversation that probably can go forever, but we have to be also worried about our time.
We have to go get packed.
Yeah, yeah, yeah, exactly.
Even though we are going two different directions, you're going west and I'm going east.
There is a lot that we could talk about with...
Thank you, Rachel Lee.
Thank you.
It's been a pleasure.