Podcast: The Future of Web Apps: Will AI Agents Generate UIs on the Fly?

Transcript

Olimpiu Pop: Hello everybody. I'm Olimpiu Pop and I have in front of me Rachel Lee Nabors. 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?

Rachel Lee Nabors: Thank you so much for the introduction. Yes, 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 FAANG 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, et cetera. 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.

Olimpiu Pop: Nice. Thank you for the idea for what you put 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 literature that we use.

Rachel Lee Nabors: Oh, yes. I used to be really big on developer advocacy. 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. I don't know about you, but you can't do business in tech without being on X and LinkedIn and probably also Bluesky and Mastodon, depending on where your friends are. If you've got friends and data, you probably need to be on Bluesky.

If you got friends in open source, you 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 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 Bluesky. 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, et cetera, 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. And 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 come in and be in like, "Hey, we need all the DMs from user X, Y, Z." 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 yes, I'm actually going to be in San Francisco doing a little pop-up soft launch for Mima next week. It's really exciting.

Olimpiu Pop: Okay. Good luck with that. We are just curious about the technical details 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.

Local-First Architecture and Small Language Models [05:36]

Rachel Lee Nabors: I have been following along with the evolution of LLMs since GPT-3. One of the things I've noticed, especially in hackathon scenes, because 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 a lot of what people started to build as soon as LLMs became 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 competitors 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 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. 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. The idea is 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.

Olimpiu Pop: Kim, thank you. So, you have multiple models in Mima or you have one that has multiple hats?

Rachel Lee Nabors: 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.

If I had just listened to my friends, I would've chosen Gemma four because Gemma four was really hot right then, but it turns out Gemma four would've actually substantially increased the latency on these summarizations and it wouldn't have provided as good summarizations as Llama 3. 2B did. So, I used Phoenix, which is a little evals library that you can set up there to run tests amongst 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 Llama 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, Facebook, LinkedIn, et cetera, 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 our Lord of 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 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, making sure your trigger warnings aren't being tripped up, et cetera. And for that, summarization's 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, 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 15 years ago we were all reinventing the wheel and learning how to build apps and 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, extra storage space, et cetera, 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?"

Olimpiu Pop: 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.

Rachel Lee Nabors: It is. I think one of the things we're going to see happening with AI assistance and personal agents in the near future is we've been building them thinking about 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. Yes, 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 walled 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, 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.

Olimpiu Pop: 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 terministic 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 someUse Caseimilar?

Model Selection and Model Evaluation Strategies [14:36]

Rachel Lee Nabors: So, I am a big fan of Hamel Husain. I don't know if you're familiar with his work, but he is like the demigod of evals, evals, evals, evals. And I come from a test-driven development background, but when I saw evals, I was like, "Oh, this is test-driven development, but for AI, got it." And Hamel is a big proponent that you don't just put together an eval and say, "Hey, Claude, which one of these outputs is better?" Hamel is a big proponent of you walk through each one of the sets. 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, yes, 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 Qwen three point something or itty bitty. Qwen is really bad at this. And I was like, "All right, we'll see. We'll see y'all." But Qwen was also really fast for being terrible at the job. So, you line them up in a row, you get your Qwen, you get your Gemma, you get your Llama 3. 2B, you're going to have to do a little research to pick the ones that seem like they are top of the line for you. And you run their 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 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, "Yes, 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 at 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 Hamel 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 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 if I wanted to build a toxicity detector using Llama 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 that's really balling and you're like, "Oh my God, is Gemma 5 it? Is it going to be faster, better, et cetera?"

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 pre-processing.

Olimpiu Pop: To summarize, your answer is it depends, right? Like all proper engineers, leaving joking aside, it's you choose your poison and see what's more important because you mentioned the local first. If you push on 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.

Rachel Lee Nabors: 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 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 a jet engine and a little two-stroke scooter engine over there. Yes, you can power one from the gas station. That doesn't mean it's going to take you there faster.

Olimpiu Pop: 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 would 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, I suppose you'll 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.

Rachel Lee Nabors: There are. I have a feeling eventually Mima's 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, et cetera. The testing for making sure that local models perform well really requires you to know your audience.

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. The latest operating system that requires certain chip set 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 is still going to be much cheaper to run than running up your ChatGPT or your Claude 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.

Olimpiu Pop: 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 do you usually do, what your friends did, what happened in the news, scrolling through it, finding ideas. So, most often than not, you just focus on things that happened in the 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. 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 to 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 you 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, right? 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 doesn't bother me. But actually behind the scenes, whatever 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 fossil fuel, it's actually a problem. So, bringing 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.

Rachel Lee Nabors: 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, 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's a new project, so we haven't necessarily crossed those bridges yet, but every 30 days it's just content older than 30 days is released into the wild. It's goodbye, it's garbage collected.

Olimpiu Pop: Yes. Green pastures.

Rachel Lee Nabors: 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 just need this common algorithm and that common algorithm." I'm like, "So, I'm basically designing a database with an interface on top of it." He's like, "Yes." 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. 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.

Olimpiu Pop: 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, whatever. Yes, that's quite good in that evolves. Well, this 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.

Rachel Lee Nabors: 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.

Olimpiu Pop: Yes, 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 L upfront, 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 by vibe these days.

The Evolution of Web and Application Architectures to Fully Use AI [29:53]

Rachel Lee Nabors: Build by vibe. Love it.

Olimpiu Pop: 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?

Rachel Lee Nabors: This is probably the most important part of the conversation we're going to have here. And it may sound crazy to 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. 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, 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.

Every 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 a widget on the fly that meets that schema's needs. It needs an image, needs a next button, it needs price. Yes, yes. 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 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, like the symbol, 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 a standard information concept. Now think about things like your software as a service, your QuickBooks, your Shopifys. These are the dashboard screens that people work with, Salesforce. The problem with these is that sure, anybody can vibe code a dashboard and a bunch of data structures and databases underneath. You can create your own in-house Salesforce.

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 yes, let's team up together and share our user bases 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 nother 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 yes, 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. Competition's 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.

Olimpiu Pop: Yes. So, standards are important. Usually, standards are brought behind companies and that put an acronym on it and then that's it.

Rachel Lee Nabors: Yes.

Olimpiu Pop: 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 ourself 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 perspective, it would be quite useful. Maybe the right question is, how are we preparing for this kind of future? What are the tools it'll be useful to have tomorrow?

Engineering Skills and Developer Experience in the Age of AI [37:24]

Rachel Lee Nabors: 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 ChatGPT 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 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, "Oh, 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 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. They're just adding vibe slop PRs and 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 under 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 saw it 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.

Olimpiu Pop: 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. We 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 skill 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.

Rachel Lee Nabors: 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.

Olimpiu Pop: We spend a lot of time into the mechanicals of things. For instance, both of us mentioned that we are traveling in the upcoming period. I was just thinking about being in the car driving, and then obviously the comfort of a car is important, but if you would 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, 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 focused 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 conversation 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.

Rachel Lee Nabors: 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, 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 and 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 these 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.

Olimpiu Pop: 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 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.

Rachel Lee Nabors: It's true.

Olimpiu Pop: It's a conversation that probably can go forever, but we have to be also worried about our time.

Rachel Lee Nabors: We have to go get packed.

Olimpiu Pop: Yes, yes, yes, exactly. Even though we are going two different directions, you're going west and I'm going east.

Rachel Lee Nabors: There is a lot that we could talk about with MCP, WebMCP, MCP apps, but you're just going to have to have me come back. Folks, if you want to keep up with my writings about the future of the web and these topics, you can find me at nearestnabors.com. That's Nabors, N-A-B-O-R-S. I've got some courses coming out on LinkedIn Learning around MCPA. If you are a LinkedIn Learning user, you can catch me there and yes, check out mima.social if you've got a chance. Cheers.

Olimpiu Pop: Thank you, Rachel Lee.

Rachel Lee Nabors: Thank you. It's been a pleasure.

Mentioned:

• Rachel Lee Nabors Blog
• React Site
• React Native Site
• Phoenix Evals Library
• A2UI Home Site
• Hamel Husain's Evals Methodology