Ep 2 - Aditya Oberai from Appwrite の全文書き起こし

speaker-1: And like on the same note and I remember telling you know, you told me this I think a couple of years ago. so and of course like you have said it at multiple places in your blogs as well. So you have said that a developer advocate, you know, has to be a technologist first, that you cannot relate to your community's problems, you know, if you could not build with the product itself. Where's that line though? You know, how much can someone advocate for a tool they cannot actually build with before it starts to actually show? Aditya: Zeshan, I'm gonna ask you a question. Right. let's say you work for a web hosting platform. Okay. like for example, at App, right? We have sites, right? We'll we'll just take this as an example for now, right? you work for a web hosting platform. Who w would you be in a better position to help the developers in your community or your customers if you know how to build web apps or if you did not know how to build web apps? speaker-1: Yeah, that kind of makes sense. Right. Aditya: Right. So it it really comes down to whether you can put your feet in the shoes of the people building with your platform. Right. Now, I'm not gonna say that, you know, let's say if you're working for a web hosting company, then you need to be an AI expert or an ML expert. Right. or if if you're in web three, you maybe need don't need to be an expert on Kubernetes. But you need to be able to build enough with your platform and the kinds of platforms that that you know in the in the space you're working in to the point where your technical depth exists at least a few levels below just the surface. Right. So you understand what's going on under the hood of these products, you understand what kind of problems your community and customers will face, and you understand. you know, if if someone does have a conflict, if if you do need to have a nuanced conversation or situation, you're able to do so. Right. With that said, developer relations can have professionals are not necessarily technical. Okay. Like, for example, every community manager may not need to have the same amount of technical skill as a developer advocate or even a developer experience engineer. because their skills will will will have to rely a lot more on on their ability to work with people, right? That that role is will will rely have to rely a lot more. Similarly, a technical writer, they will still need a level of technical ability, but they also at the same time need to hone other skills more deeply, like the writing ability. Right. developer advocates tend to end up being somewhere in the center where they need to have at least a bit of all of these. Right. But that might also be me talking just from experience and having observed. So the role is quite fluid, right? speaker-1: I think it kind of depends on what the company owns. Aditya: Exactly. It it comes down to the business goals. And me personally what what I've tried to endorse is that I think even even though

we in general try to define developer advocates as as people, you know, who are able to advocate for these developers and their companies or talk about the companies outside as well. By definition, they're supposed to be perfectly placed at this intersection, but but I believe that's not really purely possible anyway. because every company needs something different. You're always going to be biased to a certain front. Right. So it's all right to be a little more fluid there. But in general, even with that sort of an intersection, you still need to be able to build. Yeah. you still need to be able to work with the product that you know you're employer or or your community or you know whatever organization you're supporting is is is you know putting forward. So so that that's kind of where where I come from. You you need to be able to build with your own ecosystem at the minimum. Right. Anything more is great to have. Right. It's extra, it's it's good to have, but that's the bare minimum. You you need to be able to do that. speaker-1: Back to first principles. So to push on that build with it idea from a different angle and tell me if it's just me projecting or not. to me, developer relations is basically an access mechanism. Okay. good SDK and good docs mean someone with no backend experience can ship a real app. Yeah. But do you think of the job that way? As widening who gets to build what? Or is it something else from your end? Aditya: Think that's where it starts, doesn't it? Okay. increasing access and enablement is where it has to build. Right, right. Because first things first, what we're doing it is is making it easier for people to build with our systems and our ecosystem and our tools and our platform. so it it has to start there, right? But but then it it expands further, right? Once you've Allowed that sort of a discovery and access once we've started with enablement. Enablement itself can mean a lot of different things, right? Right. access itself can mean a lot of different things. When we say access, do do we mean are they able to reach the platform and try it? Do we mean are they able to build something real? Do we mean are they able to scale it up? Right. And and so if we define it in all three manners, all three manners require a different set of efforts. speaker-1: Contextual. Aditya: Exactly. And and so in in its purest sense, while it might mean increasing access, access itself can mean a lot of different things. Right. But but at the end of the day, yes, it does come down to ensuring that people are able to build with these tools, right? for some it might mean just being able to discover them. For some it might mean having the right initial education or or the tools to help them get started. For some that might mean being able to scale something real, right? so yeah, there are there are access mechanisms, right? As long as you're able to understand what access means for the particular individual. speaker-1: Yeah, I mean again,

like pretty contextual. Yeah. So and the reason why I asked this, I'll go to that. So there's a line in your one of your own blogs. So there was this blog I think which I loved a lot, like stop vibe coding every runtime. Aditya: Yeah. speaker-1: and that's where you actually drew a line, right? That and this is something even I go by, something which I have told in my team as well. That AI assisted developers are still architects, right? Yeah. Wipe coders just hope the house stands because someone else drew the blueprint. But AI coding tools are exactly what's pulling non-developers in it, right? You want more people building and you want them to understand what they ship. So how do you hold both of these? Aditya: Here's my question to you. Uh-huh. very fair that you know it's very fair to say that AI tools are bringing in a lot of non-developers and making the ability to build accessible to them. The question is, do they want to understand? Yeah. Because because I think what a lot of us misassume, and I've been guilty of this in the past, is that someone who's building with my platform wants to understand the nuance of why it is great. What I've realized is that depending on the kind of individual you're working with. Some care about why it's great. Yeah. Some just care that it's great. Yeah. And and you've got to meet them where they are at. It can't be that you force them to understand. It can't be that you force the conversation. Right. That's it's it's like saying, you know, someone who wants a a Mercedes or a Porsche over let's say a Toyota or Alexis. will want it, right? Right. Some will do so because they care about the AMG engine. Some will do so because Mercedes has prestige. that's also it's it doesn't mean the Toyota is bad. It doesn't mean the Lexus is bad. They're fantastic. Right. But but if if you are the Lexus in that conversation, right, you need to find them where they're at, right? Like for example, if all you keep telling them is is how reliable Lexus is and this is what the engine spec is and this and that, some will care, some will not, right? That's true. That's true. It it just won't matter to everyone. So you've got to meet them where they're at, right? Understand whether they actually want to know whether it's great or not. understand what they're looking for from the system. Are they looking for the most powerful tool in the world or are they looking for the easiest tool in the world? And try to make both happen. Right. Again, going back to that first one. It's access, right? What does access mean? speaker-1: Yeah. So context Aditya: Make it accessible for their situation. Yeah. And you're golden. That's what it is. speaker-1: Because following up to that, right? Like you see both sides of that in person, like you run Dune tech community meetups in Dairadun, build sessions AI first, World AMAs. So what do you see in a room where most people have fewer years in than you? that you just don't get online. Aditya: I'm glad

you've actually brought this up because I think Don't Tech Community is one of those particularly more interesting organizations that have been able to help community. Appreciate that. Appreciate that. What's interesting is is that you know when you're in a place like Bangalore, it's easy to assume that everyone has the awareness of exactly what's happening. the know-how to how on on how to operate all all of these tools and these platforms and and to be able to hack around and play with them and to make a nuanced decision. Right. It's not the same outside some of these more loaded ecosystems. Like if if you in in India, for example, right, if you head outside of Bangalore or Hyderabad or Pune or Chennai or or you know the NCR and and you go to some of the other spots, right? Yeah. Not everyone has the same awareness. Not everyone has the same opportunities. True. True. Careers don't exist the same way they do in these cities. Right. and and so what happens is is that you also see a more limited exposure on the real world implications and consequences of tooling. Right. They might have heard of her a React and a Verse L. Some of them might have tried out like an app right or or one of these other tools. Maybe they're hacking around with Claude or or Codecs. But do they understand what that means when you're building real software? Do they get the opportunity to always build real software? Some do. A lot do not, right? And and it's very easy to sometimes say that the internet is there for everyone and the exposure is there for everyone. But I don't think. without the necessary ecosystem and community and and examples of of how people operate this way. is that even it's it's it's it it's it's not even possible for people to take those first steps. And and so what we end up doing a lot of the time is is focusing on how to take those first steps, right? How to mold those those sort of mindsets and how to develop those approaches. Right. And speaker-1: Like a launch pad for Aditya: In ways, but but I think more than even a launch pad. a launch pad also happens when you're able to b start up with something, right? We're taking a step further behind. Okay. Right. I've been fortunate enough to have some wonderful mentors in that community, like like shout outs to Aksha, Tamanpreet, Ridesh, Jyoti, everyone who's been a part of this from day one. and a lot of our day ones are still there and they're helping out actively in the community. Right. because what happens is that some of these folks have had the experience, they've earned their gray hair. I talk about myself more than anyone else at this point. But they've earned their gray hair doing all the work that they have, right? and so it's it's all solely about helping get the next generation started. Allow and you know help them take their first steps, understand what first steps are even supposed to mean when it comes to tech, and help them help nurture the sort of mindset that will allow them to independently grow on their own terms in the directions that they choose. Right. And and we've started seeing results. Like I think we had a very interesting conversation the other day in that community about someone figuring out the cheapest RAM solutions. because they were trying to convert, I think, a six, seven year old laptop into a home server. Four years back we would not have had that conversation. 100%. Right. at least in their we would have had it here in Bangalore, but we're probably not right. And that's the difference we're trying to see, right? it's trying to create this exposure and widen the horizons of what tech means for us, what it can do. And allowing people to control their narratives with tech, right? Like Why should your narrative just be went to college to get a job? not saying a job isn't important. Yeah, of course. but tech is so much b wider than that, right? And and so it it tries to inculcate a love for tech. Right. We see some really fun stuff happen, you know, like the last meetup we did, which was I think back in May. my talk there was basically just me asking people to vote on what we should try to build. And building it with them, which is now converted into an actual Pokedex for all members of the community. Another individual came, showed how you can operate in the browser using a PS5 controller. And and so, you know, that's that's the kind of fun you want to have with. You speaker-1: Exactly. Aditya: know, like that's how you wanna ensure we can build a sort of a love for tech, right? Where we're able to explore and understand. also understand what you cannot do or what you should not do, ethically approach tech. Exactly. and AI. and really just help people get started experimenting with tech. So they can then start building their knowledge bases and and then really, really grow into technologists on their own right. speaker-1: Mm. I think just to add to this, you know, tech is like if you look at it the right way, tech has always been fun. Exactly. Like with the advent of AI, it's it has become much more accessible, I feel. People are making, you know, like hand controlled drones for a weekend project, things like that. So Aditya: You know twenty, twenty-five, thirty years back, games were the same magic. Exactly. You don't know what was going on, but you loved it. I think that's how a lot of us started off, right? Yeah, yeah. True, true, true. and I'm I'm just happy that AI is doing that for a lot of people who weren't necessarily just technology inclined. because I think we're we're seeing that sort of ma I'm gonna use the word magic. I think tech is magic. speaker-1: Yeah. Aditya: Right? For anyone who doesn't understand what's going on underneath. Science is always sufficiently right. And and that's what tech is. Right. So we're just seeing that magic touch upon the lives of people who wouldn't have been as technologically inclined in the past. Right. It's it's doing for a lot of consumers what games did

for me or for you or other people around us in the developer circles. Right. That's that's really what it is. speaker-1: That's that's and it's pretty nice to see people using it. Aditya: It is speaker-1: Like just to, you know, go from this part to a bit into technicality. Sure. getting into the back end part. Okay. So in there was like a piece. I think you also teased it in one of your meetups before it came out. So the apparite versus superbase. for AI builders. like Aditya: Uh-huh. speaker-1: the pieces from back in April. Okay. Yeah. So the framing is that, you know, back end is the thing the agents talk to on every turn. And clear primitive names. And predictable, you know, APIs reduce where an agent can invent something wrong. So where have you actually watched something like this? An agent inventing something wrong against a backend? Or in general, I mean. Aditya: Okay. you build apps, right? You wipe code or use AI tools. I do too. Sometimes I use AI tools, sometimes I just leave it to them. When you try leaving something to any speaker-1: Yeah, I do. Aditya: What you have done is, you know, the like this is what happens. The the lesser information you give an agent tool, agents are AI tools like these are non-deterministic by nature, LLMs are non-deterministic, right? you leave them to to do what they want, they will do whatever they think makes sense. Yeah. Right. The the lesser stuff. speaker-1: Of credits doing so. Aditya: It's expensive. Credits are getting expensive. Please do not waste credits at this point. Do not unnecessarily Yeah. speaker-1: Do token maxing. Aditya: I'm genuinely afraid of token maxing at this point. Yeah. Anyone who does it and I have friends who do it and I'm I'm I'm legitimately afraid for their credit card bills. eventually, because right now it's just cheap. Eventually it's not gonna be this cheap for sure. They're all businesses at the end of the day, they need to make money. So they will make money. And and they're just getting you dependent on these systems. It's like alcohol. I don't drink, but but I've been around enough alcoholic friends in my life to know they're all hooked. And and that's what I don't know if someone's used this analogy for agents. It's alcohol. It just gets you in and then you're stuck. speaker-1: I might make a clip out of this section. But that's a good analogy to understand. Aditya: You know that it's it's basically addiction, right? Like we talked about gaming earlier. Gaming does that to you as well. Hundred percent. we're losing track, I'm gonna get back on track. the point is this, right? huh. the less specific you are, the wider your surface of errors can be, right? which which is why we've we've preferred stronger typing with the I systems. We we wanna ensure that there's better a a better test suite around with them because we're trying to essentially limit the possibility and the potential of mistakes that these speaker-1: Adding RLs limit and tokens by Aditya: We need

more guardrails, we need better walls essentially, right? And and and that's essentially what this this perspective is about, right? Where if you can limit the potential surface of errors or mistakes that an agent can make by either making it so predictable and easy to consume the tools you're building with, by ensuring that it's easier to evaluate what an error looks like. it's much easier to make an iterative loop. Where you know you're getting more reliable answers, right? It's also easier to track errors as they happen, right? So so let's say you have a feedback loop for your agent where if it gets an error, it's able to operate on it. If you didn't have strong typing, if you didn't have proper error handling, all of that, how would your agents know whether something's gone wrong or not? speaker-1: That should no that should not be in prod zone. Aditya: Exactly. if you didn't have a test suite, even if it did something wrong, but it technically worked, your tests would fail, which would then thereby imply that something's not gone as as expected. Expected behavior needs to be defined, right? So it's really about minimizing the surface of errors that an agent can make for you. and I think that strongly typed systems, you know, strongly typed applications, better error handling, better test suites. Guards. all of those act as good guardrails for for for these sort of errors. Right. speaker-1: so like in the same blog, a little bit down, you also argue that you know typed row level permissions are easier for an agent to get right than Postgres RLS policies written in SQL. Because you can verify them by reading one page of generated code. But isn't that, you know, a tooling problem more than a permissions model problem though? Because better code gen, you know, closes that gap either way. Aditya: You know, you're right. as code generation gets better, it will be easier for a code generation tool to get all of those policies and so on correct. Right. But like we said, you're increasing your error surface. let's say you have to fill in the blank. You you have a test here, right? You either get five questions fill in the blanks, or get five subjective answers to submit. Which one do you think is easier to fill the right answer in? speaker-1: The right answer would it be fill in the blanks in a way? Aditya: Because A, like you know, the more limited your answer is, the more objective it becomes your solution. Right. I mean more than what you can fill in, the question is more what is easier to fill into. What is it easier to fill objectively fill the right answer into? Right. fill in the blank will allow you will require a level of specificity, right? So it can either be right or wrong. Right, right. There's there's not a lot of midway there. And that's what AppRite's permissions model is trying to do. Got it. it makes it easier for a human or an agent to understand what is right or wrong. And and let's be very real here. this system was designed for

agent for humans, right? It wasn't first designed for agents, but agents are also mimicking what humans can do. Right. what humans end up doing is a different story from what they can do. but but at the end of the day, if it's more reliable for a human, it's going to be more reliable for an agent, right? humans can mess up on a wider set of policies. Humans can make mistakes there. therefore agents can make mistakes as well, right? Because agenic tools are trained on first and foremost human developed systems, which now of course has then become an iterator loop with their training on agent built systems 'cause that's how we're all building today. but If you simplify, if you decrease the error surface, lesser mistakes can be made. Lesser mistakes can means mistakes can also probably be more easily caught. and so in a lot of ways, you know, the permissions model as we developed helps make a more reliable system for any application, right? Whether a human is working on it, whether an agent is working on it, it's trying to make a simpler, more reliable system for for everyone. speaker-1: Right. Bringing in, you know, another one of your pieces or like to be specific your talk. So what your MCP dev, submit talk in June gets at is a failure you cannot see. So the premise, you know, same agent, same tool, same prompt, and it still makes different tool calls, you know. So yeah, what I want to know is if you could walk me through the moment you realized, you know, none of these five things. are moving that decision like temperature, model, version, context position, schema order, and verbosity. So like are the tool itself. Aditya: You know, the easiest way to understand this is if none of those five are moving, uh-huh, your thing towards the right answers. the only way to do really understand that is is do it comparatively, right? Right. Switch up your situations and you're getting the same answers. If you're getting the same answers, which I think is anyway a rare occurrence, at that level, if you've switched all five of these criteria. Then at that point, the only thing you can do is look into how your tool has been developed in the first place. Right. so I mean, I I would treat it comparatively. Okay. Right. evaluate whether in a comparison they they give you the right answers or not. Usually though, if the tool is built properly, if the tool has given you correct answers, I think the the assumption here was that the tool worked on day one. Something changed and tool didn't work on day two. and what something changed was probably the way your model was set or if your temperature was defined to not allow for a more like if you're giving a free leash to your agent, you know, or whether your tools were in and you know ordered properly if you were leveraging your context vendor properly, all of that, right? So assuming that the tool does what it is supposed to do. the talk tried to touch upon the factors that you do actually still need to maintain at an MCP level. and and so I would say that if if something's gone wrong beyond those five metrics, it's probably the toll itself. at that point I think we're kind of like failing the premise that the toll has actually worked. so I I would probably just rarely take a step back to evaluate what you built in the first place at that point. Got it. speaker-1: Because Aditya: You know speaker-1: just to add to this, so here is where I think yours and mine were collided. Yeah. So my whole day is about, you know, pushing agency outward, expanding who gets to build and coordinate. So power doesn't just pull in a few large. Yeah. Right. but your talk also says something uncomfortable about that part, right? If an agent's tool choices are not even stable across routine model update, the moment we hand these agents real leverage like money. contract action in the world. We cannot actually pin down what they'll do. So is that something you know you can engineer your way out of? Better tooling, tests, fingerprinting, or is the unpredictability deep enough? Aditya: I think you know, when we talked about this in the talk itself, you were trying to create a more reliable system, right? Better tool ordering, better naming practices, essentially better ways to ensure that your agent is able to pick up the tools and and choose them as you'd expect them at that the tools return answers in a more reliable manner. And I think, you know, what's interesting is that a lot of teams now have been experimenting on this front. Right. I do think they're getting more reliable. I do think they're getting more effective. We are starting to see financial tools of of this sort, agentic payment s solutions. However, the biggest guard reel that a lot of these more critical tools keep is at some point of time there I do see a human in the loop process. and and I feel speaker-1: There should always be. Aditya: at least today, yeah, for anything that critical human in the loop is important. obviously how effective these tools become over time. might change that. But but for now I think It's funny that you know we are we're still back to relying on people. and we're in in situations where we were trying to take away work from people, but I do think I trust people still. Right. And it's an interesting thing to say in the AI conversation, but it all comes down to people at the end of the day. Yeah. So human in the loop is still a speaker-1: Relevant. Aditya: very relevant thing and and I would still have that in anything extremely critical. Which we do anyway, right? That's what usability testing is. That's what user research and feedback is, right? But we're still relying on humans, in in some form or the other. So yeah, I'm I'm just gonna take a moment to cheer for people and humans. And I hope you know people and humans don't forget that. Yeah, go humans. Co humans. speaker-1: So yeah. I think that sums my up my entire conversation. Thank you for coming, Arita. Aditya: Thank you. Thanks for having me. Thank you very much. Folks. speaker-1: Mm-hmm. Aditya: See you in the next one.