AI Security & the Agent-Ready Web: Experts Weigh In

I think it's really an unsolved problem, largely, you know. Because a lot of times people have way too much confidence in the agent and they get very lazy, and that's what concerns me the most. Imagine a skill or something that does an action uh but then to fetch more information to fulfill that, they get that from like an authoritative source, which could have been prompt injected. That is the invisible part where that's like not entirely obvious how that works.

At the end of the day, the agent is gonna be able to negotiate the guardrail. Eventually, this uh access is gonna get breached. And that's the hard truth we have to accept. The dependency on the GitHub workflow is going away because your code is just not that precious.

The agents will actually find a way to get into your website. But if you want to make things easier, cheaper, and faster, well, WebMCP lets you do that. We don't need to apply the last 25 years of software engineering to the tools of the next 25 years. You will be left out.

You will be replaced. The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding. Join your host, Sky Fajani, and meet Simon Maple every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today. This is the AI Native Dev.

Hey everyone, hope you're enjoying the episode so far. Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about agentics development. Whether that's talking about the latest tools, the most efficient workflows, or defining best practices. But for whatever reason, many of you have yet to subscribe to the channel.

If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favour and hit that subscribe button. It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you. Alright, back to the episode. Hi, Simon Maple here.

Welcome to another episode of the AI Native Dev. We've just wrapped up another amazing AI Native DevCon in London, and while we were there, we got some really smart people together to talk about some of the most interesting topics around agentic development today. Coming up, we have my conversation with Netlify's Dana Lawson, author and educator Max Fertman, and Tesla's very own James Moss, talking about the future of AI development for web applications. But first, the subject is security.

And I sat down with Sneaks Liran Tal, Joseph Katsialudas from GitHub, and John Gretzinger from Cisco. Enjoy. All of you, welcome. How are you all doing?

Great, thank you for having us. Absolutely. Enjoying DevCon? Of course.

Fantastic energy here today. Oh, it's good fun, isn't it? So why don't we just do a very, very brief uh intro. Tell us a little bit about yourself, 10-15 seconds.

Uh let's start. Left to right. Sure. Uh John Götzinger, Cisco, uh largely background in firewall.

Um, but recently, the last couple years more focused on agentec development and AI solutions. Lauran? Yeah, I've been doing uh dev turned into uh security and DevRel thanks to Simon, who has had that influence on my life. Thank you.

Uh I've been doing some AI security research recently, uh, so that's been fun. Similar background to Loran, security turning more into DevRel, helping developers to ship secure code. Awesome. Well actually, Loran, you kind of mentioned um a little bit around the kind of like, you know, the the the NPM securities and vulnerabilities and things like that.

Why don't we kind of like start there and we just let's talk a little bit about, I guess, vulnerabilities from a typical traditional software space to what we're looking at now? And um I know you know you you technique and others are are disclosing MCP uh CVEs as well. Is MCP security and AI security generally now um where NPM was like 15-20 years ago where dependencies coming out and people just using them because they feel like there's a massive performance increase, but they're just lacking in security skills?

Um yeah, I think there's an aspect of that. To an extent, somewhat it's the same issues and somewhat somewhere new. So there's whether the MCP server, for example, that you're using is actually like vulnerable or not. So there's the aspect of the security of the MCP server itself, and then there's like the consumer side of it.

So whether the MCP server you're using, are you like taking it from like official places? Is it trusted? Uh when MCP came out, it was uh very high-pitched and like let's use the latest. So people would just like run it off as like command strings with like you know, UVX or NPX, and then like the MCP server at latest.

So they'd get like the latest thing, and you could like rug pull them, and they would just get like new, I don't know, dependencies or whatever with code in there. So from that aspect, we kind of like haven't learned to like instill the right practices when we're like consuming MCPs. Um and it's when we talk about maybe skills later, it's kind of like the same issue again and again. Um so there are some aspects of like AI supply chain and traditional like NPM package management supply chain that really, really affect and um and implement in the same way to MCP security.

And we've been through this route right before, Joseph. Like, do you feel like we have that muscle that has just been kind of like it's it's already built there? It's we we know what we should be looking for, but we just need to apply the same methodologies to other things like skills and MCP to the yeah. Yeah, I absolutely agree with that.

I think that the the speed of development is so fast, and we are all of us trying to make the most out of it. Therefore, security keeps catching up behind this linearly. Therefore, we definitely learn from learn from the past, but awareness is not there yet, so that we are starting deploying a new technology securely from the beginning. Um that's why we have this gap every single time, as Liran mentioned.

Yeah, and I guess uh John, a large organization like Cisco, like obviously we're aware of the threats. What's the balance, do you think, between wanting developers to actually play with this technology so they get that advancement in genetic development, but also being sure you it's done at a pace that can allow for security to best practices and things to be put in place. Yeah, I mean, it's it's hard to speak for you know the whole work, but we kind of go team by team. When one team tries some pattern that works well, you know, we kind of try to apply that broadly to other teams, but uh I mean it's really an unsolved problem largely, you know, it's it's there's a new problem every week, a different tool, different thing.

But we do try to restrict access to things like you know, open claw, for example, is one of the very few tools we banned in Cisco. Um I was like, oh, I can't even get to this, which is a good thing, right? But um, our security and trust org is very intentional about what they allow and don't when it comes to coding, though. So it helps us kind of just get guidance from them.

Yeah, yeah. And do you and do you feel is is it very similar to kind of like, you know, talking of security and the adoption of dev security? Um, do you find it similar in the the adoption of AI? You'll have different groups of teams where some are absolutely eager, want to get started, others are complete skeptics, don't want to even touch it, and then probably the big bit in the middle is willing to use it, but they want to see the value first.

Absolutely. Yeah, I could I'd see that so much. I'd say it's way less unlike the skeptics. We don't really have many of those left, I'd say, in Cisco, at least I haven't really found them.

Um top-down is very, you know, supportive of AI, and we know how productive it can make us. At the same time, it can be dangerous, but again, we have intentional security policies around that. So, but yeah, it's it's largely people that are kind of never really been coders, but they want to try now because they can. Those are really the ones that are kind of the most dangerous because they put stuff out there.

They don't understand the traditional developer security controls, like don't put public, you know, don't make your private project public. Yeah. These types of basic things that agents will just do um that they're not aware of. There's actually a uh an interesting data stat that I'd love to kind of like share with you both afterwards.

But um you mentioned in a in a in a report, I think 83%, or this is maybe Cisco's data, 83% of enterprises plan to deploy agentic AI, but only 29% feel ready to do so securely. Uh I don't know if that's a stat that you're that you've that you've seen or Yeah, yeah, yeah. What do you what do you think? I want to start with you, John, but then we'll come across because this is a really interesting one.

What does not ready look like? When we say when we say uh only 27, sorry, 29% feel ready to do so securely. What what what's a sign or a flag that says this is not ready? I mean, some teams don't even have traditional security controls in like their pipeline.

So like that's number one. If you don't have that, it's it's just a disaster waiting to happen as a first thing. I mean, that's just a key sign, but I don't know. That's the basic one for me.

A good signal that things are very chaotic at a company when they're adopting MCP is like basically having lots of adoption, different MCP servers, no one knows about them, people just rediscover them using latest. Um it's very fast to adopt, uh, as in like move fast, break things, but at the same time, it's it's early and not exactly uh as like good, confident uh security hygiene to basically adopt them. So what's the interesting? Well, I think at the at the very uh like we talk about like governance and policy, what if the first thing you want to have like is like observability, right?

Like it's the thing that uh when we go back to talking about like how does this uh correlate with like NPM usage and like you know, traditional software development, if you don't really know like all the packages you're running, all the PyPIs packages and stuff across your team, you don't have that visibility. Visibility, yeah. Something that happens, like malicious packages, vulnerable packages, you know, new React, you know, zero day, whatever. If you don't really know where that's deployed, that's a problem to begin with.

And that's kind of like the same parallel with MCPs and with skills later on and whatever. Like basically you want to have a deployed visibility layer for everything the team is running and your org is running, so you could really have control over if there's like a new vulnerability, new CVE, new malicious MCP server, whatever, you are able to actually like find it to begin with. And that's like those like core beginning points. But you shouldn't try to have it, you should do or do not.

There is there is no try. Yes, there is no try. Indeed. Do or do not.

But for those on audio only, Loran is wearing a Yoda hat, just so that it that doesn't sound ridiculous. Uh Joseph, how about you? What does not ready look like for? I feel what is uh where this stems from is from the fact that we are moving in the execution layer and AI is taking actions, it can send emails and do all these things that people are getting nervous about.

So what is not is not ready feels, is visibility, governance, all these things that Lyra mentioned. I I think it's totally normal for people to have a lower risk appetite than accepting AI taking care of the execution layer. Therefore, if you see these uh cases of executives in in companies getting their emails being deleted, maybe other executives are getting nervous and the top-down gets OpenCloud being banned, which is the same as GitHub, by the way. We also don't have access to the website of OpenCloud.

Therefore, I think not ready means that I don't feel empowered to leave these agents to take care of the stuff that we might lose clients for, we might get hurt reputation-wise, and all these cases. Got it. And interestingly, when we think about how we how we actually become more ready, and actually a lot of it is education, a lot of it is us, you know, making sure the developers on our team and on our organization know these types of attacks. And in fact, Joseph, the session that you literally just gave in the in the room, just behind that door uh behind you there, um the it was a very much an attack and then defend.

So, like, let's try and work out how we can exploit, let's try and work out what the what the issues are, and then how can we write better prompts and how can we set up our system better to defend more against it? In fact, it's very similar to the to the Stranger Danger style sessions that that uh you and I both gave many times at Sneak and I think at uh at the recent conference uh Cisco Live in Amsterdam, I I did a little bit of a session there with uh uh with one of your colleagues as well.

Um do you do you find when developers are more aware of the attacks, it actually helps them? It changes their behavior? Like when they understand the attacks, does it change the way they build, change the way they develop, change the way they write prompts? Definitely.

Um that that's another workshop I gave in uh in Brooklyn in the previous conference of Tesla there. Uh, I think that when developers are aware of those, they are gonna, they are not gonna trust AI to defend themselves. Um, they are gonna build applications that have mitigated controls there, such as, for example, output filtering or dual LM, input filtering. In general, they will not give access to anything sensitive to the AI agents because eventually this uh access is gonna get bridged.

And by that, through sandboxes and all the zero trust um measures out there, sure they are aware of those, I feel they are gonna be able to do so. Otherwise, they are gonna find out the hard way. And that's the hard truth we have to accept. Um anything you gonna add?

Um I I would just add I I think developers who are security-minded are probably gonna be in that uh like box where they're always like aware of what could go wrong. But even after many attacks and stuff, like I I still feel like people do like NPX CC usage latest, just like watch the cloud code usage uh stuff. And like uh I'm like completely scared to run that because I know the moment I do NPX what could happen, like when I bring all of those dependencies, and maybe that was like you know a compromised package or something.

Um so I think it's it's gonna be hard to trust that devs and also beyond devs, just like developer citizens. Like now everyone's like empowered to be a developer, right? So you have people who do not even understand SDLC and just build apps on top of cloud code and whatever. And it's gonna be hard to expect them to follow security guidelines and practices.

So we should put all of that out. And I think like, for example, Joseph is doing like a really good job of like you know, advocating all of those things, um, which is great for their community, for the education. At the same time, we have to like build that into the workflow itself, like have proper isolation and sandboxing, and how do we treat secrets and how do we you know secure MCPs and skills from like a very uh first principles kind of aspect so that that is already by itself sort of like taken care of and like invisible to devs because otherwise I don't I'm not entirely sure that people are gonna be stopping to think about what could go wrong versus wanting to ship uh new features.

So hopefully the harnesses do get better. Uh that's something I've seen. We'll talk about it in my talk later, but um it's it's definitely something we have to bake into agentic tooling. Yeah, agree.

Uh we talked a little bit about visibility, and which I think is a key piece of um of security gener uh generally. John, um Cisco's AI defense tool um now includes an MCP gateway that actually allows you to be able to track and identify uh messages that are being sent from agent to to tool. Um this is really, really important to actually identify, okay, what's happening? Is it is there is there some badness happening from the MCP or something like that?

Uh at what stage though is this kind of like visibility versus security? Like, is this is this gonna stop issues or is this gonna at least show us something is happening and we need to stop using these types of things? Yeah, I mean it's hard. I think if you can somehow observe intent, I think that's really, you know, what was the intention going in, what the agent was trying to do, and what systems did it reach out to or talk to?

Was it really necessary to talk to the systems? If you can focus on observing those patterns, it's good, but that's really hard to kind of set that up. I think it's still kind of new. Um, but like that's where I've been trying to focus.

Like, hey, I need to add this rule to a firewall, I want an agent to do it for me or whatever, and has to do some LDAP lookup. It's like, I don't want you talking to LDAP for this, you should talk to this other system, like instilling that in and observing the patterns. Does it feel like still kind of like quite a like a when you look at like a web firewall or something like that, where you're constantly adding rules because things, you know, everyone it's constantly changing.

Is this something that is we need to just get comfortable with it being kind of a a little bit more reactive and identifying these things are happening? We need to adjust. Is it is that I mean I wouldn't say in production reactive, but more, you know, maybe sandbox environments. To pull it there, test it out, see what it tries to do before you put it in production, observe that pattern.

I mean, that's obviously what you should do first, but unfortunately, I think largely our learnings come from the reactive of it happening, and then we put our role in place. So that's just kind of how security is. But you can try to be proactive. It's just not easy.

Um so I'm sure during the next couple of days we're going to be talking about things like OWASP top tens, and there's an agentic, uh, there's an agentic applications uh top 10. I think there's a new one coming out for skills as well, skills development, which is super interesting. I think it's coming out Q3, Q4 time maybe. Uh very, very interesting.

When we look at some of the new styles of attacks that we need to be thinking about, um, not just during development, but production as well. What would you say are kind of, when we go down the line again, start with you, uh maybe Joseph, what would you say are the are the are the uh the most interesting attacks today that we're not paying enough attention to? So the things that exist that developers don't know enough about. For me, this is prone injection uh by far.

I believe that it's a risk that we have to accept. Because if we constrain too much the input there, maybe we don't give the chance to people use AI in the way that they want to use, which is used through natural language. Therefore, uh I think we should be taking active steps towards the direction of what happens from the moment that AI gets that information. Therefore, um assuming the worst that maybe sensitive data can be licked, we can apply output filtering.

Before that, we can use the technique of dual LLM or LLM assiduity, therefore, second LLM with instructions to check the work of the first LLM, which is something that um Microsoft will have dual production. And by the way, when I mentioned that it's a risk that we have to accept, that's something that we did as well. Yeah, we accepted that risk. And for that, we made sure that uh since AI can be steered in ways that we don't expect through natural language and other approaches from attackers, it's all about not giving access to data that it shouldn't have, in the same way an employee shouldn't have root access or and apply the least privilege principle in that case.

And at the same time, making sure that uh these actions are sandboxed. Because at the end of the day, the agent is gonna be able to negotiate the guardrail, is gonna be able to escape from stuff that you put around. Therefore, prompt injection is a risk that can come from external, but also from internal, through the execution layer instructions that we want to give internally in order to do our work faster, maybe, or become more productive, achieve business outcomes in general.

And even from the inside, we can prompt inject in ways that we don't expect, or intentionally or unintentionally. Therefore, for me, Simon, this is the most interesting risk that AI brings uh by far. And people and ourselves, we are getting slowly, slowly more exposed into it and more educated, learning the hard way. And sandboxing is like something which just needs to become a default.

And I probably tell more people about it than I do it myself, which is maybe a uh a confession I'm not happy to make, but yeah, it's something that we should just be natural. Yeah. How about you, Loran? What's your what's your favorite uh you have to pick one, what's your Yeah.

Um I'm gonna try and squeeze two of them. I'm gonna build on Joseph's uh prompt injection, but I think indirect prompt injection is an interesting part of it. So imagine a skill or something that does an action, uh, but then to fetch more information to fulfill that, they get that from like an authoritative source, which could have been prompt injected. So I think that is like the invisible part where that's like not entirely obvious to how that works.

And also the more you go into like complicated workflows and have to like trust this like third-party upstream kind of like indirect uh input and context into the action, um that becomes like a bit more messier to figure out how to clean the data right. And how do you even defend that, right? Because let's let's say I'm I'm reaching out to let's say a GitHub issue or something, because you know, I I need some more data. Yeah, it's a perfectly reasonable place to go.

Correct. But it's how does, you know, anyone can just like write some stuff on a GitHub issue or a get or a pull request or whatever. And as long as it's rate, as long as it's created, you know, even with a trusted source, you could get potentially malicious data that someone's just putting that in. So how do we even think about protecting it?

It's a hard one. I've I've seen a couple of like examples of how to try and defend that. One of them is um just recently, they're like just like this research that actually like runs, like actually like uh proxies the fetch of the data to like a dummy, like isolated proxy, and then watches the behavior of what happened. So it's not the actual one.

It's like a it's like a proxied agent that you can't really protect it. So you actually tell it to do it, and then you watch what happens afterwards in like an isolated environment and then judge that. So you kind of have to kind of f like a honeypot, you have to like follow it and then like judge it because you don't really know in advance what would happen. And also just because it runs well then doesn't necessarily mean in a day it's gonna come into changes.

True, true. And there's like so many, exactly. And there's like you could like fetch code and like what happens when you fetch code is like, you know, not I don't like understand the code, maybe that's like malicious, maybe not. Um there are some signals like when we did uh the toxic skills research at Snake, we saw like that some like suspicious downloads would have like zip files that are password protected.

So if you put something on like GitHub that's password protected, like why would you do it? And like the reason is to like evade antiviruses and like malware protections that need to like uh inspect what's inside. So you password protected. Um so there's like signals, but again, there's like signals, they're not entirely there.

And there's like like those, there's like a bunch of like uh methods around it, but essentially it's like it's a hard problem to figure out. So it's behavioral analysis plus whatever the agent is doing in its business logic. Awesome. So what what what do you think, John?

What's your what's your favorite? I mean, I think uh being intentional about the questions that you ask is really something I want my developers to learn because but that takes experience, right? Knowing what questions to ask. Uh because a lot of times people have way too much confidence in the agent and they get very lazy, and that's what concerns me the most is just people letting it do it.

And then they just ask it, is this secure? And of course it'll be like, I reviewed it. Yes, it is. And it's like, no, what you should be able to know what questions to ask it, like what did you check to afford this?

And like again, understanding the architecture, how it fits into when it's deployed, right? It might not know it's sitting in front of some load balancer which strips headers, and you know, so it's like, oh, it's not it's secure here because this could strip and you know assumptions about that. Yeah, I think that's uh overagency in OS variable. There it is, then that's then that one.

That one that one in a year from now, we're gonna be uh I know it's ridiculous doing things beyond a week, but in a year from now, um organizations are gonna be deploying AI agents into production much, much more, using it in development much, much more. But do you think we're gonna be uh more or less secure in our usage and in our deployment? I think more, uh especially in the enterprise setting. Maybe in the more smaller individual, probably less so.

But in enterprise, it's it's getting locked down a lot more and there's more policies and tolling coming out. But the tolling costs money, so individuals you know, don't really purchase that. But I have hope for enterprise, but the individual is gonna be tough. So more from Germany.

I would say more secure, but at the same time, we're gonna watch some uh I think very chaotic like incidents out there. I agree, I agree with both. Uh I think we are in an interesting world. Uh again, technology is growing exponentially and we are trying our best to catch up linearly.

Therefore, I'm expecting some chaos out there, but good chaos in the sense that it's gonna be helpful. Uh I don't think mature enterprises are gonna face problems. I think that um small medium enterprises that maybe when I move faster, they might be on the biggest risk because they are facing the least amount of they have the less the least maturity. And at the same time, vibe coders out there uh might be exposing themselves to a lot of security problems.

Let's see. Joseph, Laurent, John, it's been an absolute pleasure. Thank you very much for joining. Thank you.

Really fascinating conversation there, and from such smart people in our security industry today. Um let's change tack a little bit and talk about all things web AI. Hi there, Simon Maple here, uh, hosting another episode at the AI Native DevCon. Uh, and joining me here is another amazing panel.

Uh, we have Dana Lawson, the Chief Technology Officer at Netlify. We have Max Fertman, the founder and director of Codemia, and we have James Moss, a member of technical staff at TESL. And we're going to be talking about AI on the web today. So, first of all, welcome to the episode.

Thank you. I think everyone's first time on Oh no, sorry. You did a session with Guypone, right? So WebMCP.

WebMCP, and I think uh we had we had um who did we have? We had someone on the uh someone from Netlify on one of the earlier. Sean Roberts? No, I think it's been Matt Billman?

Uh it was, it was Matt Bilman. Yes, I better do better than him. So we're gonna send this to him and uh and tell him all the ways that you're better than him. You definitely do because it's review cycle right now.

Oh, excellent, we'll do that, absolutely. Awesome. Well, what do we start off with, kick off with a little bit of intros. Uh we go left to right here, um, and uh tell us a little bit about yourselves and your role.

Well, um, as you said, I'm Dana Lawson, CTO of Netlify. Um I've been in tech for, well, I don't even want to say, since the 90s. Uh I've been obsessed with developer tools and platforms for decades now. I started my career um as an individual contributor, slinging code, and have been working in this developing for developers system since New Relic, GitHub, Heptio, Envision, and now at Netlify.

So what a set of set of companies to work for as well. I know, right? There's some good ones. Yeah, yeah.

And Max? Well, before the AI era, so I was a mobile and web developer. So I was doing apps. I've been doing websites for 30 years.

And mobile app since Nokia, BlackBerry, I'm not sure if you remember that, Symbian and all the stuff. And so I've been a developer, also a speaker. Uh I've been to 75 countries doing speaking and training, doing trainings, and also a book author. So trying to explain new stuff around.

And now it's AI, everything is AI. And what's the country that you haven't been to that you really want to? There are a lot because there are 200. So yeah.

But in Europe, most of I think I have all the European, all the South American countries. Is there one that you haven't checked off yet that you really want to go to? No, I I mean it can be uh South Korea. Never been there.

Nice, nice. Yeah. Vietnam, maybe. Nice, nice, nice.

James. Hey. Um I um have been building on the web since 1999. So built my very first GeoCity site back in back in the day for my planetarian gang uh clan.

Does anyone remember Planetarian? No, just me? Um yeah, and then for the last past 20 years, kind of been building uh products mostly for startups. Right now, I'm a member of technical staff at TESL, so I'm working on our registry product, amongst many other things, uh, as you kind of have to at startup.

So yeah, love building on the web, love building products that customers love. It sounds weird, but we've got over a century of development just between the four of us. I know. I I uh did a uh recent talk and it was 150 years, and it was just three of us, and I was just like, oh my gosh, you guys are old.

Yeah, yeah, yeah, yeah. Awesome. So actually, Dana, why don't we start with you? Like uh you mentioned GitHub, Netlify.

Um, that's like two incredible like developer platform companies. Um what would you say is different about building the web platform versus a developer platform? I think the difference is really the web is a lot simpler in a lot of ways. Um, there's not as many gotchas that you have to consider except caching, and that's really freaking hard.

I think the big hard challenge with web is honestly just caching. Trust me on this. It's hard. Um, but a development platform, it's a lot more open-ended.

People can build anything they dream of, and it's usually something very technical that's feeding one of these experiences. And so the real shift is creating this obfuscation of stuff that doesn't matter to a web developer and to how you power the web. And so finding that line, but very similar. And with the rise of AI, the lines are definitely not they're they're blurry.

You know, development platform, web platform, it's an AI platform now. Um it's just how how deep in what you're building do you need to actually go? And my hot take is you don't need a lot of the nonsense for building experiences. If you're building a tech company, yes, maybe, but most people are just building applications and websites.

Also, I think that um users never care too much about web or native. They just care about using the experience. Yeah. That's right.

Sometimes they don't even know. I mean it's a QR code. They use the Q. Scan the QR code and they use the app.

I don't know if it's web or native or what. Yeah. Any differences that you uh you code to? Um yeah, I guess when it comes to those uh those kind of development tools, you kind of want to build a sandbox, right?

Where you want to build all these tools, this environment that people can go and play. You don't want to have those kind of guardrails in place. You want to enable that sort of creativity. Um like Dana said, you kind of want to enable folks to experiment and get the tools out of the way, right?

Build something interesting, build something fun, um, something that you're kind of proud of, uh, and not put those guardrails up. Yeah, cool. You uh we talked a little bit about kind of like leaning into a little bit like agent experience there. Um and this is something that I think Netlify coined, right?

Agent experience? That is right. Yeah, yeah. So tell us a little bit about um that concept.

What does it practically mean for when you're you know developing uh an app and you need to think about what the agent experience is like, how does that differ from? I mean, many of us don't have green-field applications. We're dealing with a lot of stuff that was written for humans, and now with agents it has to be at machine scale. And so rethinking about how you approach that.

You know, for instance, with CLIs, a lot of it's an interactive, and you can write scripts, bash scripts around to utilize the CLI, but the way that it was codified was for human eyes and for sequential movements of data and systems versus you know this new world that we live in where agents just work in parallel. Shoot, they work in all directions, and now you have different boundaries that you didn't have before. Yeah. Well, to say like a you know it's actually funny when I when I play with Tesla, actually, James being here, when I play with Tesla, half the time I'm like, oh yeah, I'm I'm just using, I'm gonna I'm gonna use it through Claude.

Uh and then I'm like, oh hang on, is this using the CLI? Is it using MCP? And I just realized actually I don't know, and I don't care. I don't even care.

Yeah, I don't think it matters. You d it doesn't matter. And I think really agent experience is about thinking about how those agents interact with each other, and again, utilizing intent. And so agent experience is truly just going back and re-looking at some of the systems that you built, or how you're gonna build the new ones, knowing that they're gonna be used at machine speed.

And so thinking about that, and it's like you're trying to, you know, run out all your threads, you're trying to kill the systems. Well, you're not trying to. So agent experience for me really comes down to two parts is putting in guardrails, writing intent with specs, and making it human readable as well as machine readable. And what does that mean when we talk about machine readability?

Because I think for us, you know, documentation, well-documented APIs and things like that, is it the same levels of documentation that an agent needs? Or do agents need something else to understand how to interact with it? It's the way that it's actually written. Instead of doing gits and posts, agents don't understand that.

When you want to understand what's actually being pushed through, it's writing in. I I go back to some of the basics of Python. When I first learned Python, I was like, oh my God, this is so easy. Um and a lot of machine learning was based upon Python because it's understandable.

It's not anything that you have to go and compile. You can just read it. And I think a lot of when we talk about what agents need, they want that human view because humans are speaking to the agent. So you have to speak in these parameters that aren't in machine speak.

It's it's now spoken in what's the intent and the experience that you're gonna have ultimately. That's really the shift. It's not magical. It's just it's gonna feel like dumbing it down, frankly.

That's how I feel. I'm like, oh man, I've got to make this a lot more clear so that the agent can take the correct action. Because when it's not, it's gonna have to parse through so much to figure out what those endpoints, what those services are trying to do. Yeah, very much so.

I think coming back to kind of the CLI point you were talking about there, about like thinking about um making those suitable for agents. Um they are reading, like you say, they are reading um things like help documents in terms of um how to use those TLIs, you know, passing dash H in on the command line to read that. Um but I think a lot right now a lot of people are still focused on human experience and they're not thinking about the agent experience, um, and they're not detecting that, hey, this TLI is being run by an agent, not by a human, and actually I need to tailor the experience for that agent and give it perhaps more information, less information, allow it to kind of navigate through the information that you're getting out of that CLI as well.

It's like Max was saying, like, it doesn't matter anymore. I mean, somebody was asking me, they're like, well, what if you want to get in there, look under the hood, because you're a developer? I I would ask them, why are you wasting company money if nothing's broke? Like, why are you spending your time?

Be curious, like be curious. But this this version of like spelunking for spelunking's sake is really just, I think, a personal fear of developers losing their identity because now anybody can participate because the agents are doing the heavy lifting. So now when you go and you you look at what's happening, humans are going, oh my gosh, where where's my where's where's my purpose now? And let's take it one level deeper.

Code. Obviously, and I I was chatting with uh Ryan on another episode, actually, uh Lapopoli, and and we were talking about code and the human readability of code, the importance of that versus agent readability. And the parallel I drew was, you know, years, years ago when we were writing an assembly language and binary. This is machine, machine readable, not human readable.

But now we've uh abstracted you know into different languages where actually the maintainability was more important, and so we made things intentionally more uh human-readable than machine readable. But now we're getting into the AI space. We're actually going almost like the need is the other way around. We're actually something it's more important for it to be agent readable than human readable, although the human readability, I guess, it's more about levels of trust and level, you know, when we need to look at it.

Where would you say you are, I guess, individually today in terms of the needing something to be like code to be agent readable or human readable? Well, I think that um let me give you an example on the web. Let's say the web. So I'm writing a book, and the book is on vanilla web.

I was always an advocate of using vanilla web, but why are we using React these days with coordination, for example? So is React really needed at one point? So because uh React was actually created for developer experience, for a human developer experience. It was actually needed.

But when you think about that, well, now we have other problems, you know, security issues with dependencies and all that stuff. So maybe we are going to see coming back to some base. Of course, we can get the extreme version and say, like Elon Musk said at some point, that code will disappear and agents will actually write binary code directly. But despite that extreme vision, maybe we are going to start removing some of those uh layers at the top that we had for human interaction.

And then maybe we can talk to the platform directly using just uh native APIs. Yeah. James, can you sleep at night now and uh you couldn't read the code? I think we're in a kind of a weird sort of uh half state at the moment, which is really hard to reason about.

I often think about it in terms of self-driving cars, those different kind of levels that you have. I think it's at level four, or level five is self-driving. Um, we're like full self-driving, we're kind of at that level four right now. You have to keep your hands near the steering wheel, you kind of have to keep your eyes on the road.

Um and it feels like it's in a similar way, we're kind of there with code, right? You're you're still you're still slightly involved with that, you're still kind of doing reviews, um, and you still need to be able to read that code, but ultimately um you kind of do want the agents to take more control and you for you to step back and not kind of care about some of those details so much. Um but because we're not in that for kind of full state, you have to. And I think we're definitely kind of wasting uh time uh in some cases thinking about um uh these kind of interactions between humans and agents, especially when it comes to code and how it's structured and kind of the quality of it.

Um Max, you've you've been teaching web and and mobile development for 20 plus years, as you mentioned. 25 years. 25 years. Yeah, in June 25 years.

You earn that half century. Yeah, yeah, yeah. Um what would you say is the kind of like the biggest mind shift uh in recent times now that you're you're telling students that they need to make to be truly not AI native, but now AI agents have entered the picture. What's the biggest shift that you've had to make in your life?

I think that the biggest shift that I see right now is that when you you have new people coming to the web environment, that they ask you, but do I need to learn something? Or why do I need to learn something? So my take on that is that we need to understand the fundamentals, how how everything works. You need to understand HTTP requests.

So how a fetch is being done, that you have a get post. You need to understand those stuff, even if you're not going to write that, but at least you understand what's going on. Okay. What are you asking?

If you're asking if it's possible or not, because if it's not possible, the HTML will try to figure that out with that. Maybe the solution is so complex that it will not be performance or it will not be really the best possible solution. So I think that we still need to keep for now that human criteria. And for that you need to understand the basics at least.

Maybe you're not going to write code anymore from scratch. You're you don't need to remember the fetch API arguments and how to add an abort controller or some things like that. But you need to understand the basics that when you're making an HTTP request and you are going you're pressing the back button, maybe you should abort that thing. Things like that.

So some basic ideas, I think that they are still important about software development. Uh unless until I don't know, AGI appears. I don't know if that will happen or not, or when if it happens. But at least so far, the the difference is that people actually starting from scratch right now, uh they say, but do I want to learn?

Do I do I need to understand the difference between uh a div and a section and things like that? So um and I say yes, because if you don't know that there isn't a semantic HTML and a non-semantic HTML and what's the difference in terms of accessibility, maybe your Asian is not going to do the right thing by default. So we went very quickly from code not needing to be human readable to now needing to understand the details of a div there, though, didn't we? Yeah, but but but it's not a div because of the div, it's because of accessibility, accessibility, um, things like that.

Even even when you are you are making a semantic HTML, it's gonna be better for uh Asians reading that website. But uh it depends on the agent that you're using, if you're not using the right skill or things like that. It's just taking the average website out there. So uh by default, when you when you ask, when you you are doing bycoding and you ask uh for an app, it's probably it's going to make an X.

js application by default if you don't know what's going on. So it's a little bit like actually Martin Thompson, I think it was, who kind of like mentioned, or maybe it's Martin Fowler, actually, mechanical sympathy. The idea of you don't need to like as a as a Formula One race car driver, you don't need to know the inner workings or uh and the and the detail of how to rebuild a gears uh uh uh a gearbox, but you need to know exactly how it works generally so that you can get the most out of it.

It's that kind of uh that kind of an update. It's being an operator. I think you I think you have to know enough to be an effective operator. And I think that though, you know, there's not gonna be as big of a need to have experts as it gets better.

And it's gonna happen before AGI. We're gonna we're gonna see this before there's generalized artificial intelligence. And I think that the the bitter truth is adding in a bunch of glue agents and a bunch of glue code, you're gonna have to unwind. Because I do believe your your point that it will get simpler.

We created a bunch of frameworks and harnesses and layers around code for utilities for humans and human developers to go again connect the workflows. But now that the models are getting better because we're doing great with skills, and we keep feeding skills, the context of the skills and the in the intuitive nature of what you're saying is becoming learned. And I think people sometimes forget is it's large language model, but it's machine learning. And every time we prompt, we are making the models better.

And as developers utilize the models better and we create more abstractions that train the models, the question is where do you spend your time, effort, and energy getting ready for this? And I think we're a little ways away, maybe forever away. I don't know. I don't believe that.

I think we're gonna we're gonna get to the point where building web experiences is as easy as sending a text message. And that's not too far off in the future. And so coming back to the laws of physics and science, understanding HTTP and the way that the internet works, I do believe are valuable, but you're not probably ever gonna touch that layer of the stack ever again. Yeah.

And you shouldn't have to. No, no. I kind of see it in the same way that things like the kernel, for example, right? Like I've been mostly building on the web, I've got some understanding of operating systems, but I don't know how the Linux kernel works, right?

Uh and I don't need to, uh, because it's so abstracted away from the layer that I'm working at that I, you know, it would be a waste of time to think about that. But I do need to know how HTTP requests work and how a fetch works, and that kind of one layer down is important. And I kind of see it being a similar thing, right? Like you might want to know some of the details and mechanics of how these apps fit together and um and how they're talking to each other, but you don't need to know some of the lower level details.

And that'll just get more and more abstracted as we're building kind of more and more layers on top. Let's talk a little bit about what that means for when we talk about agents being primary users of that. When um what does like user testing, what does user testing even look like when agents are agents? Well, I mean, obviously the big thing that everyone talks about right now is taste, right?

In terms, do you want the most generic app? Because you've got agents to do all your user testing, and the feedback that you've got there is just the average of the training data that they've been trained on. Probably not. Um I think that's where taste kind of comes in more than ever.

Um but uh it's a new skill. Isn't that good testing? Okay, well, it's solved. It's on GitHub.

Okay, I'll check that one out. Um but yeah, it's it's one of those things where maybe again it comes down to abstraction, right? Like user testing uh works a different way in terms of you're utilizing agents to maybe user test things around like accessibility or maybe some of the kind of uh large flows that you have within your app. Um but for things like specific details around uh you know look and feel, things like that, maybe that's where you're getting a human in the loop to make those decisions.

Um and they're able to kind of uh sort of supplant what the agent is doing to be able to enable you to do things like that kind of at a much larger scale. I'd love to talk about existing uh applications. For uh for uh, I guess uh a web developer who's maintaining that, what's the what's the practical, first practical thing they need to do to make that web uh agent ready? For make it agent ready.

So um I think that the the first thing if it's a legacy app, okay, it's uh it's different that the I mean that means an app that I coded like two hours ago, right? Okay, yeah, yeah. Yeah. But maybe it's uh Java-based or things like that.

So it can be really legacy. There are a lot of websites out there. So I think that uh I mean for the future, WebMCP is one of the solutions. I mean, probably the future is um means that different browsers and uh agents should uh implement that.

So right now you can start implementing WebMCP. WebMCP lets the website expose tools to agents, tools being just uh HTML forms or JavaScript functions. Okay um but the first um thing, so one of the so my my my session at the conference was on WebMCP, and one of the questions I I got after the session is that but uh what about people that actually don't want Asians to access your website? So the first question is that we will have that situation where a lot of websites or a lot of companies they want want patients that we can use the web notice.

Yeah, something like that. So well first, if you actually want Asians to use I mean, if you don't want I mean you are trying to uh I don't know, try to turn off the sun, you it's not gonna work. And Asians will actually find a way to to to get into your website. But if you want to make things easier, cheaper, and faster, well, WebMCP lets you do that by exposing functions that the agent can call directly on the front end on the browser session with uh the user's context, local storage, index TV, with uh accessing the camera, the user's camera.

Think about the I think that one example, the one good example is the uh the meta display glasses that looking into the future if we are going to use those AR glasses. Uh the meta display glasses, they have uh web app support. So you can run a web app these days, and they have an AI agent inside the glass. So then uh sometimes I mean you yeah, you can use your finger to move around, but you probably the Asian will do more most of the stuff.

So then if you have a web app, an application that is running there, you want to be more Asian ready. And for that, I think that WebMCP will be the way to go. Yeah, and that's again, it's it's you have to just accept that it's gonna be artificial users across the entire experience. From those that are accessing the site, pulling the information, utilizing WebMC to give the experience in another view, or for the developer behind the keyboards.

And I've been thinking about this a lot, and so at Netlify, we started up an open source project called Access, which is just a scoring system that is completely open to everybody to come contribute to get your systems agent ready. It goes through a series of checks and balances in some libraries that can come and see, like, are your endpoints ready? Have you made this change to your site? And really, you know, we're just trying to get the community because nobody has the answers right now.

I think the interesting part is like, how do you make a website the web agent ready? We're all doing that right now. Everybody, I mean, somebody upstairs is probably getting the web agent ready, if I had to guess. Um, the reality is there's not one technologist or company to rule them all, that this is a time and space where the development community globally are coming together and defining these workflows, defining how to become agent ready.

And I think that's an actually really exciting part of our job that didn't exist. I mean, I've been writing code forever. Finally, we're getting to do something new and fresh, even though I learned that you know it's the birthday of AI and it's 70 years old. But it feels new and fresh to me, I'll tell you.

Do you think there'll be a time when the browser will be legacy? Oh man, I don't know. I'm I I I love the browser. I love the internet.

Like my partners at Netscape. You know, I work it at Microsoft. Working at Microsoft was not great in my family. Uh they're like, what?

I I don't think it's going anywhere. I think the browser will just be in a new form. You know, you're gonna have more heads-up displays. It's still gonna be a browser behind the scenes, it's still gonna be the web.

Um but I do feel like HUD's gonna come in and not Dorky Oculus VR, but but true heads-up displays. We're seeing that with Meta as an example. But again, that's just another, that's another version of a browser. It's just it's it's just HTTP.

TCP IP, man. All the way down. Um That's right. Yeah, I think the thing for me right now is accessibility.

Actually, it feels like a really um kind of like a powerful skill that we should kind of lean into when it comes to agents accessing the web. We spent years and years and years making the web semantic, like it's inherently semantic. Um, and um agents have allowed us to kind of like make our sites more accessible almost for free in some ways, right? They're the their um the training data covers a lot of kind of accessibility techniques and best practices.

And so um, if you ask an agent, say, make this website accessible, it will do a pretty good job right now. It won't be amazing, but it'll do a pretty good job. And to me, that kind of accessibility layer is something that uh works great for agents, right? Um agents don't want to read the whole DOM.

Like they don't care about a lot of the parts, but what they do care about is um the kind of accessibility tree. And they can use that to look at elements on the page, interact with it. Um uh and so they're able to use it kind of as a human would do. Um, but uh I think, yeah, more and more of that will get abstracted away.

And you again, just like code, um some of these things just kind of won't exist. And let's talk about the value of skills here, because I think that's that's all of a sudden becomes very, very important with things like accessibility and those types of things. Um given that skills are kind of quite language agnostic, um, do we do we feel like there's gonna be kind of like front-end specific skills to help with things like that, like accessibility and things like that? Yeah.

What even is front-end in a world where uh MCP, right? Where where a lot of this stuff disappears. Um, you know, as someone who is less technical, do I need to know exactly what front end is? You know, I just want to build a cool app that's gonna help me to do uh specific task or make my life easier.

And so maybe what we're calling front end just becomes more of a kind of generic design uh element, whereas you don't need this kind of specialized skill of uh uh you know understanding HTML and being able to take a set of design or a set of kind of um requirements and turn that into something that can be rendered in a browser. So yeah. So it's interesting. Actually, it's the the front end and web, the front end and back end just completely there, there's no there's no we're all full stack.

There's no back. There's no content management, there's no git, there's just code. Yeah. And it and to people that don't know, I mean, it's again, they they do not understand that's under the hood, and you have to start asking yourself, were these things that we built now needed, or can there be simplification across the board to build and generate those experiences?

Because as agents become more prevalent, you're gonna have hyper-personalized experiences that are just for you. And those experiences and those websites will be created on the fly geared towards you. And I think it's gonna be really interesting on how we do approach that. And I don't know if it's gonna be front-end or back end, but regarding skills, I think for some stuff you don't need it, but that's still very much needed for guardrails and governance outside of the web.

Like, I would not I would not YOLO without a skill for a database. Like, trust me on this. Like, you would have somebody that doesn't know anybody bork that database. I've seen it happen because I was working on a skill for a database and uh broke it.

Um, I think that there's still a need in especially larger uh environments where it really is a team sport I'm building to have a good skills library. Because if you want to make your company participate and really think about the experiences that you are bringing, I think skills are required because you're gonna unleash them. And so that's becoming more of the developer and the architect's you know reign of control is ensuring that those guardrails are put in place so that people can safely do the things they need to do.

And and in fact, people already assume that there's trust by default in these platforms. And so, you know, do one wrong thing, you're gonna be in a news rail. So yeah, I mean the blinds are blurring of of what we say are front end and back end because now the experiences are ephemeral and and they can just happen magically, it feels magically, but there's a lot of guardrails to make that magic happen in the background, and that's where we come in and put skills and specs. I I think the content of the skill will evolve, right?

Right now it's very direct, and it's like, you know, use these HML elements, use this design language, this design library, these components, this front-end stack. Um I think what we'll see is a move towards the skills being more about intent, right? Um, if we think about things like the SOL document for Claude, for example, it doesn't have a lot of do this, don't do that. Um it's more around um what the intent is and kind of the kind of end goal and what you care about.

And I think we'll start to see a translation of um skills uh into those kinds of documents rather than just being a specific list of do's and don'ts and a kind of checklist of how you do it. Everything is evolving really quickly these days, even the web. And the problem is that right now we don't have models that are being trained every day. So we are working with models that were trained a year ago or something like that, which means they don't have the last year of uh web evolution.

So that's when skills appear. So they can teach the model, hey, we need you have this API now and that API, so you don't need to fall back to a library or things like that. You should use that library. That base baseline library that we have right now, baseline is how compatibility works across different browsers this year.

So I think skills are are are going to be useful for for web design and web development on CSS or JavaScript APIs uh to modernize uh what the model already knows. I won't argue about that. I agree with skills. Um Dana, I think it was about five minutes ago you said uh there is no GitHub, only code.

There's only code. I just want to I just want to all I wanted to say was I think it was I think it was Dana from Ghostbusters who I know. So there there is no Dana only Ghostbusters. There is only Zool.

And it was it fits so perfectly. Well, that is my GitHub handle, Dana is Zool. So check out my there is amazing. So No, I mean I I'm an ex-hubber and it it and it pains me to say that, but like the dependency on the GitHub workflow is going away because your code is just not that precious.

Um it is and it isn't because now with it with truly atomic rollbacks and the ability to fix fast and create software factories underneath, there is still a need for revisioning. Do not get me wrong. But the whole Git workflow, like that's for developers. That's for developers.

Well, what what's the key thing an agent requires in some kind of uh, you know, whether it's consistency, whether it's persistence in something? What is that, first of all, what is that thing they want to persist? Is it like uh specs, skills, context, uh instructions? What is the thing?

I I still believe in source control. Yeah. I'm just saying like I believe that source control as a company won't need to be a thing. It's gonna be more localized to the experience, or it's gonna be more localized closer to the builder.

And it's gonna be in the systems that they're utilizing to make the changes versus calling back and creating developer workflows that are traditional. Now, a lot of us have dependencies on GitHub actions and all of the things that we utilize for our CI CD platform or CI CD pipelines to ship code, but as CI CD becomes easier, and really that's all that matters. So, what does an agent need to know? How to roll back and how to push forward.

I don't care how it happens, it just that's all it needs to know. And you can use you know git as your um version control, or you can use anything else because most users or most new builders are not gonna know. They just are gonna say, oh, that change doesn't look good. Roll it back.

They're going back to FTP. Oh, we are yeah, you know what? What's old is new again. I'm here for it.

Just SCP direct into production. You know what? Why not? Why not?

Because you say you say this is what agents need to know. Is this gonna be completely abstracted from developers? Do developers even need to know about this now? All happening through the agent?

I think it's kind of a different set of requirements, right? We keep talking about abstraction, and I think Git is one of those things. I wanted to be abstracted. Git frustrates me all the time.

It's an incredible piece of software, but it's also very, very annoying at times. And when I'm teaching folks how to do engineering, it's often the thing that is always tripping them up, right? But it's great for agents, right? Um and so I think building layers over the top of Git that that do the abstraction.

Um, I also think we're kind of at a point where we can start rethinking how these tools work, right? We don't need to apply the last 25 years of software engineering um to the tools of the next 25 years. We should kind of use this as a bit of an opportunity to rethink things completely and not follow those same patterns, but kind of just tweak them a bit and get them to work for agents. But are we going to rethink that, or the agent will do that?

We don't know. Oh, we get to. That's the fun bit. I think it's gonna be us.

I think that's again where we we put the humans back in because I know y'all have all probably been there too. You're sitting there vibe coding and you're up to like 500, 600 lines, and then you look and you're like, what is going on here? Like 400 of this can be, it's just garbage. And you tell the agent, hey, 400 of the 400 lines of code, this is garbage.

You need to go in there, clean this up because I don't know what you're doing. Start over. Guess what? It can do it.

Um, but it also can do it bad, bad, and bad, and bad, and then good. You're absolutely right. We're not quite there, but we're gonna get there. Because every time me, you, and others go through that workflow, we're making it better.

We're we're we're training it, we're training it to be better. And so where where's the line gonna blur? But again, we're pretty far off from there. Yeah.

Let's ask one quick fire question uh where I'd love an answer and then a brief why. Uh the question is: what would you say is the most important thing that uh a web developer should either learn uh or change over the next 12 months or so? So why don't we start with yourself, Dana? In the next 12 months, a web developer should embrace AI.

I see a lot of resistance, a lot of people saying, I can do better, a lot of fear, and the best thing they can do is embrace it, be curious, and start using it and becoming a force in nature because you will be left out. You will be replaced. The world is now AI native and our space is as well. And so the best thing I can do is like stop obsessing about your frameworks and start obsessing about your workflows and start becoming AI native because the expectations for you to produce just got amplified.

Yeah, I would say that maybe being a better AI user. And that means uh as a technical person, understand a little bit about AI, so how the model works. What is the model? Maybe trying with a local model, even if you're not going to use that one, but understanding how it works, why context matters, so understanding the context window, all the stuff that maybe if you're a web developer, you have never done machine learning or things like that, you don't really know.

And if you if you're trying to use it as a magic solution, uh you will probably get worse results. So I think that uh learning a little bit about AI, uh a little bit about prompting, understanding why prompting is important, the context, how the context is being organized and managed and compacted and all that stuff will make you a better developer. Um so I would say probably using uh AI to enhance your learning. AI doesn't just have to be about generating code for you, but what about using it as a way to kind of interview about topics you might be interested in learning?

We've kind of talked about using fundamentals, you still kind of need to know a little bit of those right now. Um thinking about using AI in that sense, I think, is probably super, super powerful and not be scared of it. Really interesting, actually, because actually one of the one of the folks on our team, uh Alan Pope, uh, he's building out some of the some of the TESL learning. So we're trying to build a learning platform.

Kind of like one of the things I mentioned to him is we need to be skills first. Like create skills that are module that are education modules that you can kind of like plug into your agent and then do your learning through the agent versus a traditional learning platform. So super, super curious about that. Dana, Max, James, thank you so so much uh for not just presenting amazing sessions and about to present amazing sessions, but uh but also for joining me today and sharing all your wisdom and knowledge on the on the podcast.

I really appreciate that. Thanks. And uh and thanks for listening and tune into the next session. Bye for now.

Really fascinating conversations uh throughout in both uh of the discussions here. Hope you enjoyed the episode. If you want to hear more from the guests featured in this episode, their full DevCon talks have been linked in the descriptions below. So that's it for this episode.

See you next time. The AI Native Dev is brought to you by Tesla, the package manager for skills and context. Your hosts are Guy Pajani and me, Simon Maple. Our producer is Tom Dowler.

The AI Native Dev is not just a podcast, it's a community. And we host a monthly meetup of Tescofficts at Temple Legends. It's etc.io forward community to learn more about this.