# Securing Agentic AI and Redefining Web Development

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-06-16

## Transcript

I mean, 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, 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 going to be able to negotiate the guardrail.
Eventually, this...
access is going to 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.
And 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 hosts, Guy Pagiani, and me, 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.
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.
All right, 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 Furtman, and TESOL'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 Katsialoudis 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 intro.
Tell us a little bit about yourself.
10, 15 seconds.
Let's start left to right.
Sure.
John Gutzinger, Cisco.
Largely background in Firewall.
But recently, the last couple of years, more focused on agentic development and AI solutions.
Yeah, I've been doing a dev turned into security endeavor, thanks to Simon, who has had that influence on my life.
Thank you.
I've been doing some AI security research recently, so that's been fun.
Similar background to Leran, security turning more into DevRel, helping developers to ship secure code.
Awesome.
Well, actually, Leran, you kind of mentioned a little bit around the kind of like, you know, the NPM kind of like securities and vulnerabilities and things like that.
Why don't we kind of like start there?
Let's talk a little bit about, I guess, vulnerabilities from a typical traditional software space.
to what we're looking at now.
And I know, you know, you, Nick, and others are disclosing MCP CVEs as well.
Is MCP security and AI security generally now 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?
Yeah, I think there's an aspect of that.
To an extent, somewhat it's the same issues and somewhat somewhat new.
So there's whether the MCP server, for example, that you're using is actually vulnerable or not.
So there's the aspect of the security of the MCP server itself.
And then there's the consumer side of it.
So whether the MCP server you're using, are you taking it from official places?
Is it trusted?
When MCP came out, it was...
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 would go 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.
And it's...
when we talk about maybe skills later, it's kind of like the same issue again and again.
So there are some aspects of like AI supply chain and traditional like NPM package management supply chain that really, really affect 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...
It's already built there.
We know what we should be looking for, but we just need to apply the same methodologies to other things like skills and MCP.
Yeah, I absolutely agree with that.
I think that 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 the past, but awareness is not there yet.
so that we are starting deploying a new technology securely from the beginning.
That's why we have this gap every single time, as Leran mentioned.
I guess, John, a large organization like Cisco, 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 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 hard to speak for the whole world, but we kind of go team by team when one team tries some pattern that works well.
We kind of try to apply that broadly to other teams.
I mean, it's really an unsolved problem largely.
There's a new problem every week, a different tool, different thing.
But we do try to restrict access to things like OpenClaw, for example, is one of the very few tools we banned in Cisco.
I was like, oh, I can't even get to this, which is a good thing.
But our security and trust org is very intentional about what they allow and don't when it comes to coding.
So it helps us kind of just get guidance from them.
Yeah.
And do you feel, is it very similar to kind of like, you know, talking of...
security and the adoption of dev security.
Do you find it similar in 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 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.
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 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 project public these types of basic things that agents will just do that they're not aware of there's actually an interesting data stat that I'd love to share with you both afterwards.
You mentioned 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.
I don't know if that's a stat that you've seen.
Yeah.
What do you think?
I'll start with you, John.
come across because this is a really interesting one.
What does not ready look like?
When we say only 27, sorry, 29% feel ready to do so securely, 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 their pipeline.
So that's number one.
If you don't have that, 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 are adopting MCP is basically having lots of adoption, different MCP servers, no one knows about them, people just rediscover them using latest.
It's very fast to adopt, as in move fast, break things, but at the same time, it's early and not exactly as good, confident security hygiene to basically adopt them.
Well, I think at the very, like we talk about governance and policy, the first thing you want to have is observability, right?
It's the thing that when we go back to talking about how does this correlate with NPM usage and traditional software development, if you don't really know all the packages you're running, all the PyPI's packages and stuff across your team, you don't have that visibility.
If something that happens, like malicious packages, vulnerable packages, new React, 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 the same parallel with MCPs and with skills later on and whatever.
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 a new vulnerability and you see the new malicious MCP server or whatever, you are able to actually find it to begin with.
And that's those core beginning points.
But you shouldn't try to have it.
You should do or do not.
There is no try.
Yes, there is no trial.
For those on audio only, Laurent is wearing a Yoda hat, just so that that doesn't sound ridiculous.
Joseph, how about you?
What does Not Ready look like?
I feel where this stems from is from the fact that we are moving in the execution layer and AI is taking actions.
You can send emails and do all these things that people are getting nervous about.
So what is not ready fields is visibility, governance, all these things that Lira mentioned.
I think it's totally normal for people to have lower risk appetites than accepting AI, taking care of the execution layer.
Therefore, if you see these cases of executives in companies getting their emails being deleted, maybe other executives are getting nervous and the top-down gets...
OpenClaw being banned, which is the same as GitHub, by the way.
We also don't have access to the website of OpenClaw.
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 hired reputation-wise in 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 making sure the developers on our team and our organization know these types of attacks.
And in fact, Joseph, the session that you literally just gave in the room, just behind that door behind you there, it was 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 issues are.
And then how can we write better prompts?
How can we set up our system better to defend more against it?
to the Stranger Danger style sessions that you and I both gave many times at Sneak.
And I think at the recent conference Cisco Live in Amsterdam, I did a little bit of a session there with one of your colleagues as well.
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.
That's another workshop I gave in Brooklyn in the previous conference of Tesla there.
I think that when developers are aware of those, they are not going to trust AI to defend themselves.
They are going to build applications that have mitigated controls there, such as, for example, output filtering or dual LLM input filtering.
In general, they will not give access to anything sensitive to the AI agents because eventually these...
access is going to get breached.
And by that, through sandboxes and all the zero trust measures out there, should they are aware of those, I feel they are going to be able to do so.
Otherwise, they are going to find out the hard way.
And that's the hard truth we have to accept.
Anything you want to add?
I would just add, I think developers who are security minded are probably going to be in that like box where they're always like aware of what could go wrong but even after many attacks and stuff like i still feel like people do like npx cc usage latest just like watch the cloud code usage stuff and like 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 So I think it's going to be hard to trust that devs and also beyond devs, just like developer citizens, like now everyone's 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 going to be hard to expect them to follow security guidelines and practices.
So we should put all of that out.
And I think, for example, Joseph is doing a really good job of advocating all of those things.
which is great for the community, for the education.
At the same time, we have to build that into the workflow itself, like have proper isolation and sandboxing and how do we treat secrets and how do we secure MCPs and skills from a very first principles kind of aspect so that that is already by itself sort of taken care of and invisible to devs because otherwise I'm not entirely sure that people are going to be...
stopping to think about what could go wrong versus wanting to ship new features.
So hopefully the harnesses do get better.
That's something I've said.
We'll talk about it in my talk later.
But it's definitely something we have to bake into agentic tooling.
Yeah, I agree.
We talked a little bit about visibility, and I think it's a key piece of security generally.
John, Cisco's AI defense tool, Now includes an MCP gateway that actually allows you to be able to track and identify messages that are being sent from agent to tool.
This is really, really important to actually identify, okay, what's happening?
Is there some badness happening from the MCP or something like that?
At what stage, though, is this kind of like visibility versus security?
Like, is this going to stop issues or is this going to 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 that 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 it's really hard to kind of set that up.
I think it's still kind of new.
But 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.
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 like when you look at like a web firewall or something like that, where you're constantly adding rules because things, you know, everyone is constantly changing.
Is this something that is, we need to just get comfortable with it being kind of a little bit more reactive and identifying these things are happening.
We need to adjust.
Is that?
I mean, I wouldn't say.
in production reactive but more you know maybe sandbox environments to play there test it out see what it tries to do before you put in production observe that pattern i mean that's obviously what you should do first but personally i think largely our learnings come from the reactives of it happening and then we put a role in place like that's just kind of how security is but you can try to be proactive it's just not easy 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.
then 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 maybe joseph what would you say 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 prompt injection by far.
I believe that it's a risk that we have to accept because if we constrain too much the inputs 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, I think we should be taking active steps towards the direction of what happens from the moment that AI gets that information.
Therefore, assuming the worst, that maybe sensitive data can be leaked, we can apply output filtering.
Before that, we can use the technique of dual LLM or LLM massagery, therefore a second LLM.
with instructions to check the work of the first LLM, which is something that Microsoft can 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.
We accepted that risk.
And for that, we made sure that 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 and apply the least privilege principle in that case.
And at the same time, making sure that these actions are sandboxed because at the end of the day, the agent is going to be able to negotiate the guardrail, is going to 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 prone 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 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 confession I'm not happy to make.
But yeah, it's something that we should just be natural.
How about you, Laurent?
What's your favorite?
You have to pick one.
What's your?
Yeah.
I'm going to try and squeeze two of them.
I'm going to build on Joseph's prompt injection, but I think indirect prompt injection is an interesting part of it.
So imagine a skill or something that does an action, but then to fetch more information, to fulfill that, they get that from an authoritative source, which could have been prompt injected.
So I think that is the invisible part where that's not entirely obvious.
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 input and context into the action, 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 say I'm reaching out to, let's say a GitHub issue or something because, you know, I need some more data.
It's a perfectly reasonable place to go.
But It's how does anyone can just write some stuff on a GitHub issue or a pull request or whatever.
As long as it's created, 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 that?
It's a hard one.
I've seen a couple of examples of how to try and defend that.
One of them is just recently, there's this research that actually runs, 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 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.
You kind of have to, like a honeypot, you have to follow it and then 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 going to change it.
True, true.
And there's so many, exactly.
And you could fetch code and what happens when you fetch code.
It's like, understand the code.
Maybe that's malicious, maybe not.
There are some signals, like when we did the toxic skills research at Snake, we saw like...
that some suspicious downloads would have zip files that are password protected.
So if you put something on GitHub that's password protected, why would you do it?
And the reason is to evade antiviruses and malware protections that need to inspect what's inside so you password protect it.
So there's signals, but again, there's signals that are not entirely there.
And there's like those, there's a bunch of methods around it, but essentially 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 do you think, John?
What's your favorite?
I mean, I think 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.
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, is this secure?
And of course, it'll be like, I reviewed it.
Yes, it is.
And it's like...
You should know what questions to ask it, like what did you check for this?
And again, understanding the architecture, how it fits into when it's deployed, it might not know it's sitting in front of some load balancer, which strips headers.
So it's like, oh, it's secure here because this gets stripped and assumptions about that.
Yeah, I think that's over-agency in OWASP.
There it is, then that's that one.
In a year from now, we're going to be, I know it's ridiculous doing things beyond a week, but in a year from now, Organizations are going to be deploying AI agents into production much, much more, using it in development much, much more.
But do you think we're going to be more or less secure in our usage and in our deployments?
I think more, especially in the enterprise setting, maybe in the more smaller individual, probably less so.
But in enterprise, it's getting locked down a lot more and there's more policies and tooling coming out.
But the tolling costs money, so individuals don't really purchase that.
But I have hope for enterprise, but not the individual.
It's going to be tough.
Awesome.
So more from John.
I would say more secure, but at the same time, we're going to watch some, I think, very chaotic incidents out there.
I agree.
I agree with both.
I think we are in an interesting world.
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 i don't think mature enterprises are gonna face problems i think that small medium enterprises that maybe when i move faster they might be on the biggest the 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 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.
Let's change tack a little bit and talk about all things WebAI.
Hi there, Simon Maple here, hosting another episode at the AI Native DevCon.
And joining me here is another amazing panel.
We have Dana Lawson, the Chief Technology Officer at Netlify.
We have Max Furtman, the Founder and Director of Codemia.
And we have James Moss, a member of technical staff at TESOL.
And we're going to be talking about AI on the web today.
So first of all, welcome to the episode.
Thank you.
Everyone's first time on no.
No, sorry.
You know, you did a session with guy, right?
Web MCP and I think We had we had who did we have we had someone on the someone from Netlify on one of the earlier Sean Roberts.
No, I think Matt Billman Oh, it was.
It was Mattie Bowman.
Oh, my boss.
I better do better than him.
So we're going to send this to him 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, why don't we start off with, kick off with a little bit of intros.
We go left to right here.
And tell us a little bit about yourselves and your role.
Well, as you said, I'm Dana Lawson, CTO of Netlify.
I've been in tech for, well, I don't even want to say, since the 90s.
I've been obsessed with developer tools and platforms for decades now.
I started my career as an individual contributor, Sling and Code, and have been working in this developing for developers system since New Relic, GitHub, Heptio, Envision, and now at Netlify.
Wow, what a 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.
I was doing apps.
I've been doing websites for 30 years.
And mobile apps since Nokia, Blackberry, I'm not sure if you remember that, Timbian, and all the stuff.
And so I've been a developer, also a speaker.
I've been to 75 countries.
Wow.
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 go to?
Well, there are a lot because there are 200.
So, yeah.
But in Europe, most of it, I think we have all the European, all the South American countries.
And is there one that you haven't checked off yet that you really want to go to?
No, I mean, yeah, it can be South Korea.
Never been there.
Nice, nice.
Yeah.
Vietnam, maybe.
Nice, nice, nice.
James.
Hey, I have been building on the web since 1999.
So I built my very first GeoCity site back in the day for my planetarian clan.
Does anyone remember planetarian?
No, just me?
Yeah, and then for the past 20 years, kind of been building 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, as you kind of have to at startups.
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 did a 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.
Awesome.
So actually, Dana, why don't we start with you?
You mentioned GitHub, Netlify.
That's like two incredible developer platform companies.
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.
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.
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 blurry.
You know, development platform, web platform, it's an AI platform now.
how deep and 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 users never care too much about web or native.
They just care about using the experience.
That's right.
Sometimes they don't even know.
I mean, it's a QR code.
They scan the QR code and they use the app.
I don't know if it's web or native or what.
Any differences that you go to?
Yeah, I guess when it comes to 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 guardrails in place.
You want to enable that sort of creativity.
And 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, something that you were kind of proud of and not put those guardrails up.
Yeah, cool.
You talked a little bit about kind of like leaning into a little bit like agent experience there.
And this is something that I think Netlify coined, right?
That is right.
Yeah, yeah.
So tell us a little bit about that concept.
What does it practically mean for when you're developing an app and you need to think about what the agent experience is like?
How does that differ from you?
Many of us don't have greenfield 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.
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, it's actually funny when I play with Tesla, actually, James being here, when I play with Tesla, half the time I'm like, oh, yeah, I'm just using, I'm going to use it through Claude.
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 even care.
Yeah, I don't think it matters.
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 relooking at some of the systems that you built, or how you're going to build the new ones, knowing that they're going to 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 go back to some of the basics of Python.
When I first learned Python, I was like, oh, my God, this is so easy.
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 agents.
So you have to speak in these parameters that aren't in machine speak.
It's now spoken in what's the intent and the experience that you're going to have ultimately.
That's really the shift.
It's not magical.
It's just, it's going to 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 going to 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 thinking about making those suitable for agents.
They are reading, like you say, they are reading things like help documents in terms of how to use those CLIs, you know, passing dash H in on the command line to read that.
But I think right now a lot of people are still focused on human experience and they're not thinking about the agent experience and they're not detecting that, hey, the CLI is being run by an agent, not by a human, and actually I need to tailor the experience for that agent and give it, you know, perhaps more information, less information, allow it to kind of navigate through the information you're getting out of that.
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 and look under the hood because you're a developer?
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 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 look at what's happening, humans are going, oh my gosh, where's my purpose now?
And let's take it one level deeper, code.
Obviously, I was chatting with Ryan on another episode, actually, 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 years, years ago when we were writing an assembly language and binary.
This is machinable, machine readable, not human readable.
But now we've abstracted into different languages where actually the maintainability was more important.
And so we made things intentionally more human readable than machine readable.
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 that is 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 needing something to be like code to be agent readable or human readable?
Well, I think that, let me give you an example on the web.
Let's take 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 coding agents, for example?
So is React really needed?
At what point?
So because 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, 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 records.
But despite that extreme vision maybe we are going to start removing some of those layers at the top that we had for human interaction.
Maybe we can talk to the platform directly using just native APIs.
Yeah.
James, can you sleep at night now and you couldn't read the code?
I think we're in a kind of a weird sort of 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.
Level five is self-driving.
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.
And it feels like in a similar way, we're kind of there with code, right?
You're still slightly involved with that.
You're still kind of doing reviews and you still need to be able to read that code.
But ultimately, you kind of do want the agents to take more control and for you to step back and not kind of care about some of those details so much.
But because we're not in that kind of full state, you have to.
And I think we're definitely kind of wasting time in some cases, thinking about 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.
Max, you've been teaching web and mobile development for 20 plus years, as you mentioned.
25 years.
25 years.
Yeah, in June, 25 years.
You earned that half century.
There you go.
What would you say is the kind of like the biggest mind shift in recent times now that 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 teaching?
I think that the biggest shift that I see right now is that when 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 fundamentals, how everything works.
You need to understand HTTP requests.
So how a fetch has been done, that you have to 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.
What are you asking?
If you're asking is it possible or not?
Because if it's not possible, the agent will try to figure that out with, and maybe the solution is so complex that it will not be performant 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 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'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.
Unless until, I don't know, AGI appears or something like that.
I don't know if that will happen or not or when, if it happens.
But at least so far, the difference is that people actually, starting from scratch right now, they say, but do I want to learn?
Do I need to understand the difference between a div and a section and things like that?
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 aeration 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 it's not a div because of the div.
It's because of accessibility, accessibility, things like that.
Even when you're making a semantic HTML, it's going to be better for it.
Asians reading that website.
But it depends on the Asian that you are using, if you're not using the right skill or things like that, it's just taking the average website out there.
So by default, when you are doing bi-coding, and you're asked for an app, it's probably going to make a next 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 was Martin Fowler actually, mechanical sympathy.
The idea of you don't need to like, as a Formula One race car driver, you don't need to know the inner workings and the detail of how to rebuild 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 an understanding.
It's being an operator.
I think you have to, know enough to be an effective operator.
And I think that though, you know, there's not going to be as big of a need to have experts as it gets better.
And it's going to happen before AGI.
We're going to see this before there's generalized artificial intelligence.
And I think that the bitter truth is adding in a bunch of glue.
agents and a bunch of glue code you're going to have to unwind because i do believe 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 intuitive nature of what you're saying is becoming learned.
And I think people sometimes forget 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 going to get to the point where building web experiences is as easy as sending a text message.
And that's not too far from 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 going to touch that layer of the stack ever again.
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?
And I don't need to because it's so abstracted away from the layer that I'm working at that, 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 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 how they're talking to each other, but you don't need to know some of the lower level details.
And that will just get more and more abstracted as we're building kind of more and more layers on top.
And James, let's talk a little bit about what that means for when we talk about agents being primary users of that.
What is like user testing?
What does user testing even look like when agents are...
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.
I think that's where taste kind of comes in more than ever.
But...
There is a new skill.
Is there?
Good tasting.
Okay, wow, it's solved.
It's on GitHub.
Okay, I'll check that one out.
But yeah, it's one of those things where maybe again it comes down to abstraction, right?
Like user testing.
works a different way in terms of utilizing agents to maybe use a test things around like accessibility or maybe some of the kind of large flows that you have within your app.
But for things like specific details around, you know, look and feel, things like that, maybe that's where you're getting a human in the loop to make those decisions.
And they're able to kind of sort of supplant what the agent is doing to enable you to do things like that kind of a much larger scale.
I'd love to talk about existing applications for, I guess, a web developer who's maintaining that.
What's the practical, first practical thing they need to do to make that agent ready?
For making agent ready?
So I think that the first thing, if it's a legacy app, okay, it's different.
That means an app that I coded like two hours ago, right?
Okay, yeah.
But maybe it's Java-based or things like that.
So it can be really, there are a lot of websites out there.
So I think that, I mean, for the future, WebMCP is one of the solutions.
I mean, for the future, it means that different browsers and agents should implement that.
But right now, you can start implementing WebMCP.
WebMCP lets the website expose tools to agents, tools being just HTML forms or JavaScript functions.
But the first thing, so one of the, so my session at the conference was on WebMCP, and one of the questions I got after the session is that, but what about people that actually don't want Asians to access their website?
So the first question is that we will have that situation where a lot of websites or a lot of companies, they...
won't want Asians.
We need a web nosy.
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, I don't know, try to turn off the sun, it's not going to work.
Asians 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 by exposing functions.
that the agent can call directly on the front end, on the browser session with the user's context, local storage, in the TV, with accessing the camera, the user's camera.
I think that one example, one good example is the meta display glasses that looking into the future if we are going to use those AR glasses, the meta display glasses, they have web app support.
We can run a web app these days, and they have an AI agent inside the class.
So then sometimes, I mean, yeah, you can use your finger to move around, but probably the agent will do most of the stuff.
So then if you have a web app, an application that is running there, you want to be more agent ready.
And for that, I think that WebMCP will be the way to go.
Yeah, and that's, again, you have to just accept that it's going to 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 and 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 the web agent ready?
We're all doing that right now.
I mean, somebody upstairs is probably getting the web agent ready, if I had to guess.
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 love the browser.
I love the internet.
Like my partner's at Netscape.
You know, working at Microsoft was not great in my family.
They're like, what?
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.
But I do feel like HUD's gonna come in and not dorky Oculus VR, but true heads up displays.
We're seeing that with Meta as an example.
Again, that's just another version of a browser.
It's just HTTP.
TCP IP, man.
All the way down.
That's right.
Yeah.
I think the thing for me right now is accessibility actually feels like a really powerful skill that we should lean into when it comes to agents accessing the web.
We spent years and years and years making the web semantic.
It's inherently semantic.
make our sites more accessible almost for free in some ways, right?
The training data covers a lot of accessibility techniques and best practices.
And so 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 works great for agents, right?
Agents don't want to read the whole DOM.
Like, they don't care about a lot of the parts.
What they do care about is the kind of accessibility tree.
And they can use that to look at elements on the page, interact with it.
And so they're able to use it kind of as a human would do.
But I think...
Yeah, more and more of that will get abstracted away.
And again, just like code, some of these things just kind of won't exist.
And let's talk about the value of skills here, because I think that all of a sudden becomes very, very important with things like accessibility and those types of things.
Given that skills are kind of quite language agnostic, do we feel like there's going to be kind of like front-end specific skills to help with things like that, like accessibility and things like that?
Yeah, I mean...
What even is front-end in a world where...
Where a lot of this stuff disappears, you know.
As someone who is less technical, do I need to know exactly what frontend is?
I just want to build a cool app that's going to help me to do a specific task or make my life easier.
And so maybe what we're calling frontend just becomes more of a kind of generic design element, whereas you don't need this kind of specialized skill of understanding HTML and being able to take a design or a set of requirements and turn that into something that can be rendered in a browser.
So, yeah.
So it's interesting, actually.
The front end and back end just completely.
We're all full stack.
There's no content management.
There's no Git.
There's just code.
To people that don't know, I mean, it's again, 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 going to have hyper personalized experiences that are just for you.
And those experience and those websites will be created on the fly.
geared towards you.
And I think it's going to be really interesting on how we do approach that.
And I don't know if it's going to be front end or back end, but regarding skills, I think for some stuff, you don't need it, but it's still very much needed for, for, 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 broke it.
I think that there's still a need in especially larger environments where it really is a team sport on 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 going to 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 in fact, people already assume that there's trust by default in these platforms.
And so, you know, do one wrong thing, you're going to be in a newsreel.
So, yeah, I mean, the blinds are blurring of what we say are front end and back end because now the experiences are ephemeral and they can just happen.
magically, it fills 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 think the content of the skill will evolve, right?
Right now it's very direct, and it's like, you know, uses these HTML elements, use this design language, this design library, these components, this front-end stack.
I think what we'll see is a move towards the skills being more about intent.
If you think about things like the sole document for Claude, for example, it doesn't have a lot of do this, don't do that.
It's more around what the intent is and the end goal and what you care about.
And I think we'll start to see a translation of skills 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 work.
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 web evolution.
So that's when skills appear.
So they can teach the model, hey, 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 baseline library that we have right now, baseline is how compatibility works across different browsers this year.
So I think skills are going to be useful for web design and web development on CSS, on JavaScript APIs, to modernize what the model already knows.
I won't argue about that.
I agree with skills.
Dana, I think it was about five minutes ago you said there is no GitHub, only...
There's only code.
All I wanted to say was, I think it was Dana from Ghostbusters.
I know.
There is no Dana over Zool.
There is only Zool.
It fits so perfectly.
That is my GitHub handle, DanaZool.
Oh, really?
Is it really?
Amazing.
No, I mean, I'm an ex-Hubbard, and it pains me to say that, but the dependency on the GitHub workflow is going away.
your code is just not that precious.
It is and it isn't because now 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.
So what needs to change?
What's the key thing an agent requires in some kind of, 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 specs, skills, context, instructions?
What is the thing?
I still believe in source control.
I'm just saying like, I believe that source control as a company won't need to be a thing.
It's going to be more localized.
to the experience, or it's really more localized closer to the builder.
And it's going to 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 CICD pipelines to ship code.
But as CICD 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 version control, or you can use anything else because most users or most new builders are not going to know.
They just are going to 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 this is what agents need to know.
Is this going to 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 it is one of those things.
I want it to be abstracted.
Git frustrates me all the time.
It frustrates everybody.
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?
And so I think building layers over the top of Git that do the abstraction.
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 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.
Are we going to rethink that, or the agent will do that?
Oh, we get to.
That's the fun bit.
I think it's going to be us.
I think that's, again, where 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 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 lines of code, this is garbage.
You need to go in there and clean this up because I don't know what you're doing.
Start over.
Guess what?
It can do it.
But it also can do it bad, bad, bad, bad, and then good.
And again, we're not quite there, but we're going to get there because every time me, you, and others go through that workflow, we're making it better.
We're training it.
We're training it to be better.
Where is the line going to blur?
But again, we're pretty far off from there.
Let's ask one quickfire question where I'd love an answer and then a brief why.
The question is, what would you say is the most important thing that a web developer should either learn 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 of 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 as a technical person, understand a little bit about AI, so how the model works.
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're trying to use it as a magic solution, you will probably get worse results.
So I think that learning a little bit about AI, a little bit of 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.
So I would say probably using 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.
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...
Folks on our team, Alan Pope, he's building out some of the TESOL learnings.
We're trying to build a learning platform.
One of the things I mentioned to him is we need to be skills first.
Create skills that are education modules that you can plug into your agent and do your learning through the agent versus a traditional learning platform.
Super, super curious about that.
Dana, Max, James, thank you so, so much for not just...
presenting amazing sessions and about to present amazing sessions, but also for joining me today and sharing all your wisdom and knowledge on the podcast.
I really appreciate it.
Thanks.
A pleasure.
Thanks for having me.
And thanks for listening and tuning to the next session.
Bye for now.
Really fascinating conversations throughout in both 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 TESL, 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 monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more.
And I hope to see you there.