About this talk
This fireside chat with Matt Bilman explores the transition from developer experience (DX) to agent experience (AX) in software development. The speaker discusses the impact of coding agents and AI tools, such as ChatGPT and Opus, on how software is built and the role of developers. He emphasizes the importance of creating products that cater to agent interactions rather than solely traditional coding practices. This shift in focus compels companies to rethink their development tools and optimize for productivity gains that coding agents provide. Bilman also highlights the need for adaptability in the software landscape, as more builders enter the space and companies face competitive pressures to innovate rapidly. He suggests that while the number of software engineers may change, their roles will evolve to encompass broader responsibilities as building software becomes increasingly accessible.
Full transcript
I'd like to announce uh Utter Boat on stage for a fireside chat with Matt Bilman. [applause] And to give you a little bit more background on Artur, uh he actually created a community AI builders with the intention to set up a community without any hierarchies to find out. He did need to organize some things. uh today they are active in locations like Amsterdam for the Netherlands, Berlin,
London so on. So give it away. Thank you Gina. Um and thank you Matt for this beautiful uh presentation. Um we're going to have a fireside right now. So if you want to hear a bit more about the details, uh please stick around. Um yeah, you explained that we went from optimizing for developer experience for a few decades to uh now agent experience. >> Yeah. >> Um
maybe uh can you just wrap up for the people that weren't here like what what what is changing on a system level? >> I mean what what's changing for us is really that developers have always been doing a pretty broad job, right? Like but the core distinction to whether you could be a developer or not was in whether you could write and read code or not, right?
Like and it was sort of like this binary distinction between almost like the priest class that could read the sacred codes beneath the surface of the software and make magic happen and then all the other people that that didn't have access to that level, right? like and now over the last couple of years since since chatb came out in in 22 and then milestone around like when
the first Opus model like Opus 3 or so came came out and really started like to to make longer scale software development viable towards like the point where cloud code came out and started like giving us this pattern of like a CLI agent that can write software and interact with anything. We've moved to towards a very different world that's only going to accelerate where the where reading
and writing code is mainly going to be something that agents do for us and the task of building software moves up a level from that. Um, and that means that as someone building developer tools, I'm no longer going to be building tools in like a code centric world. Um, where it's all about like driving things from the code, giving as much like clarity around what's happening in
the code, giving us like little steps between from code to production. It's now really an agentcentric world, right? like where I got to build a product essentially for the coding agents so that the humans operating those agents can interface with our product and have a great experience and that's really changed like a lot of very foundational things about how we think about building a product like like
Netifi and right now that's pretty specific to the dev tool category right like everybody in the dev tool category has kind of like by now realized that they have to build for agents since coding agents have have become so strong. But it's going to generalize to any product in the future as agents become more and more normalized and and not just focused on on writing software but
also on just like doing autonomous tasks, right? Like so it's a big shift in the world both from DX to AX and from UX to AX. Okay. So, you think every product should optimize for AX? >> Yeah. Yeah. I I think if you're not thinking about optimizing for agents and for like building a great agent experience right now, there's probably some competitor of yours that that that
is um and that competitor's product might end up looking very different. and it might end up being headless and it might almost end up feeling more like a like an infrastructure a dev tool APIdriven product or something like that or it might not right like it it it might also be like more of an orchestration surface area for a lot of agents to work together and so
on right like if you're not paying attention to that you you risk that people are starting to see really big productivity gains with the agents they work with, right? Like developers that started working with cloud code suddenly started feeling, wow, I like I could never go back to like just sitting and writing all of this code. >> We know that feeling very well. Yeah. So rush. >>
Precisely, right? Like but then imagine you give that developer a tool that says like well here your clot code is not really welcome. You kind of have to write your code by hand, right? Like and your competitor has a tool that say here your clot code is really welcome. and it'll work even better with us than without us. Which tool do you think they will pick? Right?
Like, and you'll start seeing the same as non-developers start using more and more of these tools like Cloud Co-work or um managed agents in the cloud or from either from from any of the agent providers, right? Like and those agents starts having like a lot of context and memory and they've built skills for them and they've trained them. they're going to start feeling a lot more productive.
And then if they go to your product and it's like your agent is not welcome here, but we have a little chatbot you can interact with and your competitor is saying like just point your agent at this URL and it's now fully able to use our product and you can just talk to your agent and we'll drive everything and we can also drive the agent from our
product. Like where do you think your users will go? Right. >> Yeah. No, good point. Um, yeah, we just saw that you've made some great optimizations to your own product, like the markdown, special website, a special website for agents. Uh, yep. >> You optimized your docs. You optimized your CLI. >> Yeah, >> you have an MCP. Yeah. >> Maybe quick question like MCP versus CLI. I'm I'm
sure maybe some people are wondering what's the latest on that. So CLIs for any of the CLI based agents is probably their favorite tools. CLIs and and um and code, right? Like there's also ways to give them not CLIs but but but really easy ways to make small TypeScript programs that use your product, for example. They love that, right? like um to do that they still need
context around your product, right? Like they probably don't have all of your CLI and that training data unless it's been around for a very long time and then it's probably changed since then and it's going to confuse them, right? Like so you somehow need to ideally also get context in front of those LLMs so they can use whatever tool you give them. in that context today like
there's been there there's so many different avenues it can comes from early on it was all of these like cursor files and claude files and then it's somewhat standardized on agents MD and claude MD because like why would we want just one standard um and then skills then MCP came around first as like a protocol for sending context right like and then skills came around as another
alternative to packaging up context. Um, so there's always this separation around like even if you like whether you have one thing or the other, right? Like you need to get context in front of the of of the agent and the most controllable way to do that is either through MCP or skills, right? Like and then the other part is that like all of these like CLI tools,
TypeScript tools, whatever work great for the kind of agent that is that has a sandbox to write code in and and execute bash programs in. But there's also going to be a bunch of lighter weight agents that don't run in that kind of environment where their sandbox is maybe a browser, it's a local agent or it's like more like a chat TPT environment than than a cloud
code environment, right? Like and and there MCP is kind of still like a remote MCP is kind of still the only way to to to really give it a good way to get context of just like talking directly with web requests to to your APIs. Um, but I there's definitely been a a shift from initially thinking that like MCP is going to be everything and we all
have to do everything through MCPS to like realizing that MCPS probably have a smaller niche and like the tools themselves is bigger than just the context and and you need to really invest in those tools and those are often CLI tools. And you also mentioned the example where they had this beautiful CLA and then they couldn't get an O token in an easy manner. Can I now
send my agents to Netify and have them sign up and get an API key or >> Is this something you optimize or are you not scared of having too many agents on Netlifi? So the fun thing is that before Netlifi I started the predecessor to Netifi in 2013 that was called Bit Balloon and the first like it's called Bit Balloon like launch your bit into the cloud
right like um and the way it worked was that you would just go to the homepage of Bit Balloon and there would be a big folder like big drop zone saying like drag your front end into the cloud and you would just like drag your folder I would upload it give you a URL and then if you had wanted to keep that URL, you then had to
go claim your project and and then it would stick around. Um, and we carried that flow over into Netlifi's Netifi drop at a point. So, you can still do that in in Netlifi. Um and that was like the first thing we started then exposing first when when chat tippity when openi la la la la la la la la la la la la la la la la la
la la la la la la la la la launched the chat tippity marketplace with assistance how like how like there's one of these many things that you optimize for for a moment and then it like disappears who knows where they've gone yet but we built like a plugin for their marketplace that allowed chat TBT to like just deploy to Netifi without any interaction and give the user
a URL where they can go claim the project if they actually want to keep it. And since we've been doing that for like more than a decade now, we're so used to like we've built all the fraud and mal like malicious intent detection, all the processes for dealing with like the kind of stuff that people try to put on our service that we really don't want there.
Um that we probably more prepared for this world of like agents doing the same than than than most other companies, right? like and now we've opened it up even to the CLI, right? Like so now an agent can grab our CLI and just deploy a project, give you a URL without even having signed up for Netifi and then it will get a URL back that it can
send you to say like if you want this to stick around otherwise we delete it after an hour, right? like you have to go like either log in or sign up and claim this project and in that process the agent through the CLI will also get a a a token and now have access to to to that account right like so we've thought a lot about these
flows where the agent can start interacting with Netlifi where it can start doing things and it can just as the relevant point send you a URL and say please give me permission and then it can go on working and if you go to netlifi.ai, right? Like there's literally just a fetch netifi. And start deploying and a copy button and you just copy paste that to an agent.
If you do that, like I I did that with my open claw, right? Like I just told it fetch this once that was done like it it gave me a URL to authorize it and now it can like do this kind of works on on my projects in the in the background. >> Yeah. And it it loads skills as well then or >> Yeah. So when when
an agent goes to Netlifi.ai, we give it a markdown where we explain to it um how to install Netifi's CLI and Netlifi's skills um and what it should do right after that in terms of like how do you either deploy your first project or authenticate with like get your user to give you access, right? Like so once the agent has visited that URL and done that step,
it now have all the context on our platform. It knows all the primitives we have. It knows that we have blobs in a database and it knows even like we we'll even describe like when should you use blobs, when should you use a database, when should you use like netify identity and so on, right? Like um so it sort of gets superpowers just from visiting that URL.
And how important is limiting the amount of tokens for example? Are you optimizing for that as well so that not every agent is completely full with the docs? >> Yeah. Yeah. I mean it it's for sure skill skills like initially this was like a really big problem with MCP and especially with people that stuffed a lot of tools into the MCP because every tool description in that
MCP server would be loaded into the context of every single LLM call once you had that MCP installed. Right? Like so early on when MCP come around it was not like I think like super basis MCP early on had like 60 tool calls right like and if you add that plus one other MCP you're already at a point where the LM starts degrading in performance right like
skills are fortunately like better they have their risk as well right like but they're much better because like they you you only get like the skill catalog in the context And then the actual like description and context from the skill is loaded on demand. And and sometimes the agents are smart enough to do some of that in like a sub agent if they only need the skill
for a little bit and sometimes it sticks around in your session. Um but for sure like in in the whole art of context engineering keeping that context as small as possible is is is is really important because in the end if you measure like if we start thinking about how we like track our agent experience and whether it's good or whether it's bad or or so on
right like part of the parameters there is like if someone prompts their agent to do something that involves our product like how how fast how much friction does the agent encounter in that how fast can it do it and how many tokens does it cost the user to do it right like that becomes >> yeah um you also mentioned that you have your own agents your agent
runners like your own lovable type of environment um >> can you tell a bit about who is using that and um how you make sure that they are behaving well. So agent runners is both like there's a version where you just you land at Netlifi you say create a new project you have a prompt box and you can start creating a project and that way like similar
to to any of the sort of like VIP coding platforms but like a big difference is that it's not our own agent like we we don't have like a netifi agent or something like that it's us we have our own sandbox infrastructure and we have our own workflow infrastructure so we can orchestrate like longer very autonomous runs of claude code, codec cli, gemini cli, we'll probably add
open code in the future as well, right? Like um and we use it a lot internally to build netifi now, right? Like it's kind of like the building block for a lot of our async engineering work, right? like where we kick out work where every agent run can go do a task and then the result is a preview deployment with a unique URL and every sandbox is
like an isolated environment. Um if you use Netifi DB in a project every sandbox has like a full branch of that DB and can't touch the it can test like all your migrations and everything. you can go view how things look like, but it can't touch production, right? Like um and you can do all like you can do a lot of different agent runs in parallel because
they each have their own branch, right? Like um so for us it's kind of like by now when I look at app.netifi.com which is our core dashboard that's like we we we've been around since 2015, right? Like so this is like a 10-year-old React app with a lot of complexity and a monor repo and so on, right? Like um and again you wouldn't want to you wouldn't
want to try use it like you can't really use something like loable on on something like that. But when I go look at the pull request page for for for that repository, typically about 50% of the pull requests on that repository are created with agent runners. And a lot of those are then like some of those are developers that spin off async task, right? Like we have
an integration with linear. So when like a linear ticket that seems simple comes in, it's just like spin up an agent run and see if it solves it, right? like um but then it's also our product designers working directly in there um and uh support might jump straight in there and try to fix something and and if it works they'll open a poll request I'll be in
there a bunch right like so so we use it in that way for our existing code bases and then we're building whole new like internal tools and products with it where like our HR team have been building a lot of like one of the early ones was our um we replaced culture amp with our own in-house software for our sentiment survey and so on right like and
there in the past if we wanted to do that right like it's like our HR business partner is is is driving that she has a ton of domain knowledge she knows exactly how every like everything about privacy governance like what type of questions visualizations how this fits in our culture in the has to build something like this, we would need to pair her with like a product
manager that could try to take that domain knowledge and then translate it to some engineers that would then do like two week sprints and then show it to the HR business partner and some of it would be right and some wrong and you would have like that whole feedback cycle and would be too slow and too expensive for us to ever even consider touching it, right? like
now she can go in she can build all of this entirely within Netifi and then when she gets to some sensitive points we have like one engineer come in and help right like so when she gets to the point where it's like okay now I need to get the employee data from Bamboo HR and see like and link that to the surveys and so on that's like
potentially sensitive data and so on right like you want an engineer to come help with that part oversee it unlock her and and tap off and now she can build again, right? Like and that unlocks for us building like a ton of in-house software that we would never built before and it allows a lot of our domain experts to become software builders in a way that would
just not have been possible. >> Yeah. And if anyone can just build their own internal tools, like what will that mean for SAS and for the web and for maybe our businesses? >> I'll start with the web like I think it's going to be fantastic for the web because like and and and I like that because I my big like I started the whole presentation was like
we we I started the company to help build a better web, right? Like the web is the one open platform without any owner. You're not renting the platform. You you you buy a domain and you own a part of it in a way, right? Like and you can do do what you want. But it's also the only platform that can distribute software at the speed that agents
can build it, right? like the whole model of like app stores and downloading software with software installers starts really being a pain when when agents can constantly build code and and and iterate. So for the web it's going to be like suddenly and it's good for us we're suddenly seeing that everybody's building web apps now right like for SAS it's not so good right like I think
this whole SAS apocalypse is a very real thing right like the build versus buy equation have really really shifted right like before if you looked at like like top Silicon Valley tech companies like Facebook Uber Google they would buy relatively few SAS products because they would prefer to build their software in-house, but then anyone that didn't have that amount of engineers and resources, they would be like,
"We we have to buy something. We can't build this." And that like the point where you can now start saying, "No, now it's better for us to build it." That's just like dropped dramatically down. And also because like sure like an example for us, right? Like we built our own alternative to Sendesk in in-house and it's now the way we we do support, right? Like we've been
Send customers for 10 years. It was a great product, but like they wanted to stuff agents down our throat. We wanted to build our own agents and at some point we then built our own Sendesk around those agents instead of the other way around. But obviously we haven't built all of Sentisesk, right? Like there's tons of stuff in Sendisk that we haven't built because we don't use
it. Other companies probably use it. We don't right like we use like a little sliver of synis and for most customers of SAS companies it's like that right like they have all of these features and you use a small set of them so when you build this software in-house it's not like now we have to build all of this it's like we have to build the part
we really need and then we can build it for us and now we can start building a few more things that only we need that would never make its way into like a SAS because like it's just not relevant to anyone else. Um, and that that makes a really big difference. And I think so, so I think this like SAS apocalypse is a very real phenomenon. I
think we'll see lots and lots of of of market share shift from SAS traditional SAS companies to infrastructure and dev tool and API companies, right? Like >> talking about infrastructure like what do you see is there the trend like more um edge uh functions and >> the the main thing is just like that what everybody is is seeing right like just this massive amount of of of
of throughput and massive amount of people building right like we've seen our top of funnel explode right like now we're typically having more than 45,000 signing up people signing up for Netifi every day, right? Like and those are building like immense like immense volumes of of of web applications, right? Like so the throughput through our system has has gone up and you see that across every DevTool
company essentially, right? like every DevTool founder I know is is is is seeing a similar like surge in in in builders and and throughput and some some software is having a really hard time keeping up with that. um and some products were not geared to that, right? Like we always sort of like built the whole platform around that idea of high throughput. Um and and and that's
meant that it's like a very good fit for our architecture where for others we will probably see like shifts in like what the tool set looks like and and what the components we build around look like to components that that handle not so much like the peak scale of a single product but the scale of just like people building massive amount of smaller tools all the time
that they're constantly iterating >> Yeah. Very interesting to hear what your future thoughts are because like how many people are deploying on Netlifi? >> I mean we we've we've now onboarded more than 13 million users to Netlifi, right? Like um and and as I said like we're we we're now like like it's wild right like it took us 5 years to cross a million users in Netifi
and then um took us like five years more to reach 5 million and and now we are onboarding more than a million users every month right like it's it's pretty >> yeah you're definitely on the good side of the SAS apocalypse. Um, but what about software in general? Do you think that data then becomes the only important thing and that we have agents try to make adaptive
user interfaces and maybe cross all of our employees. We they will check what should be static and what should be different per per employee. So my my my guess is like there's a lot of debate on on on that, right? like are we going to stop building software and just have agents and and like I think we're going to build like almost everything in this is driven
by this like you've probably heard the phrase it's become so familiar this phrase of Jevon's paradox right like that when the cost of some resource goes down demand for it just always goes goes goes up right like and the cost for building software is like going down down down which means that like software is pretty useful, right? Like so why not if it's cheap to build, why
not build a lot of it, right? Like um and I think we will see a lot of like like generative on the-fly UIs is starting to be at a point where where they use where they're really cool for some things, especially things like data explorations and so on, for coordinating a lot of people and humans around doing some work. I think it's always like it tend to
be really useful that we all have something that is shared that's in the same reference and where I sent you there, you see the same that I see and we can like talk about it and like and and I think that that's not really ever going to change. So I think we're still going to be building a lot of that kind of of of software that's not
like change like it's just going to be a bit of pin if if if the kind of software you go to try to figure out what's happening is looks looks different every time you go there, >> Whether you're a human or whether you're an agent, right? Like >> Yeah. And Yeah. I mean, and it's also nice to um build software to keep an eye out on our
agents in general. Yeah. >> Because do you see that do you think that people then also spend less time online and just have our agents more online and that we just build fancy like logging software or human in the loop software for when we actually need >> in general like since 22 when this started right like I've always tend to look a lot of like what am
I what am I actually seeing happening versus what are people speculating happening, right? Like the first speculations was constantly, oh, like we're going to have much less developers, right? Like, oh, agents can write code now. So, so developers are going to go away. And meanwhile, I was seeing like every dev tool I know starting to like massively increase their signups, right? Like, so it's like if that's
what's happening, maybe like there'll be this belief that like suddenly that'll stop and it'll be something else. like most likely is that that's probably what's going to keep happening, right? Like so with a lot of these trends, I kind of tend to look at what's actually happening and and sadly I'll see since since all of these agents come around, I'm not seeing people being less like, oh,
now I'm going to just sit on the beach and have my agents do stuff. On the flip side, I think everybody is even more in the like now that we can build so much, it feels like I should be building all the time and I should be online all the time and and it's almost like I see people getting burned out from that. I see the opposite
happening, right? Like I see people getting drawn into like the almost the gamified feeling of like just one more prompt, just one more prompt. Let me see what happens. Just one more prompt, right? like and I think people actually almost have to fight for doing the opposite sometimes and and remember like okay if if if if I have if I am to come up with something really
creative to make these agents do I need to clear my head a bit I need to take some steps away. So so again I I think that's probably going to keep happening in some ways right like they're probably going to pull us more in rather than like pulling us more offline. >> Yeah. So what what do you recommend to us developers in terms of like what improving
the agent experience of our software? Um, yeah. I mean, think of think of it similar to like when you think about building great software for for for people, you have to to do that, the most important is to sit down and look at how people are using your software without too many notions of like how they should be using your software and so on, right? like and
it's really about like trying to understand what they're trying to achieve, how well they can achieve it, and how you need to change your software to make it simple for them, right? Like, and that's kind of the same with agents, right? Like you have to actually sit down with these different agents and put your notions a bit aside and see like if you prompt them to try
to do something with your software, how how are they approaching it and can they do it? And if and and at every point of friction what can you do? Then there's like one difference from from humans and agents and that is like automating that process over time with humans is pretty hard, right? Like you need like some supply of very willing humans to to to forget everything
they just learned and then try your software again or like you but but with agents that's not that hard, right? like you can actually build these scenarios and and start start automating them. We've been working on that and that, right? Like it changes a lot of how you do software development from like a more deterministic predictable version where you write like unit tests and integration tests and
to a more to to a version of like almost automated user research for agents, right? like where you start building these scenarios of here's what I want to tell the agents it should try to do here's like the ground like this agent has no prior notion it hasn't installed anything and I'm trying it to get started or this agent has installed all of our skills and our
MCP and it's equipped with everything and I'm telling it what to do and then you kind of have to score right like it's never going to be a binary like success or non success. It's going to be like how long how many token does the agent need to to spend at this? How many tool calls? How long like can it do it fast or can it or
or does it need human intervention? Does it need human in the loop? How often is like so you kind of got to build those frameworks and then those grading mechanisms and then find the way of orchestrating so you can run that on a regular basis as new agents come out as new models come out as you change your context files and your MCP servers and so on
and we're working uh we're working a lot on on on that at at >> like you wrote tests or eval right like really think about them as as as as eval. Um, and we're starting to build more and more of them. Um, and our VPAI Sean Roberts is working on on a on a on a larger project there that that he's going to open source. So, so
stay tuned for for for that. Um, and now there's also companies that are starting to emerge like um, new startups that are starting to emerge just like you had like we've had big startups like using.com and so on around like the whole [snorts] how do we formalize user experience. We've had performance testing companies built around like lighthouse scores and like constantly evaluating that. And now we're starting
to see like because you can automate that, right? like the first startup sort of emerged to say like how much can we like build a tool set that anyone can use. Um like one that's like in the early stages is 2027.dev dev that's starting to build tooling in the space. But there's several there's several right like because it's going to be a really common challenge to automate
these kind of evals and to keep understanding because agents also evolve so fast right like so you have to keep understanding is our agent experience it is it still good >> yeah no absolutely um I think we all got some good inspiration now to start to optimize our agent experience and even write tests and evals for that. And 2027 is a tooling kit for that. >> That
that's a startup like 2027.dev is a is a based startup like I I've met the founders and an ex event there and so on, right? Like they're very early stage. We we we're going to launch an an open-source project uh tentatively named Axis. um that that's that's going to be like more of a like just open source toolkit for starting to build these kind of scenarios and
so on, right? Like but I think this is an area that's going to like evolve really rapidly over the next year. >> Yeah. And in terms of CLI um and all these other uh or MCP tools like what what are some tips you have for improving the structure or the schema there? We again what I what I said in the talk right like think of context as
the UI for LLMs right like LMS in the end have like their training data and then whatever context they have in the session and that's mainly what determines how they respond to a prompt right like and every part of your system has some ability to influence that context right like CLI tools one of the strengths of CLI tools is that every there like it's different from like
an an API typically just returns data, right? Like a CLI tool typically tells you in the console what it is doing, right? Like and that's one of the reasons that that CLI tools are great because like that's context, right? like you can literally explain to the model like how the tool works not just what did I just do but also like what follow-up commands might you want
to do and how do those look like and so on right like so think of context as the UI for LMS and the same with MCP right like it's called model context protocol for a reason right like it's a way for you to get a little foothold inside the agent loop where you and feed context to the to the model. Um, and and that's a that's a
real thing you should think about, right? Like how do you use that to engineer the context that the model has so so it can use your >> And as a quick hack, would you then suggest okay, I don't have a CLI yet. let's add some metadata to our API with what the logical next request would be >> I mean even even that yeah like even like that's
again think about all the touch points that the LLM will have even even if you have a CLI right like they might not yet have your CLI installed right like so they might just try to decide like oh I don't have the CLI but like I have some old training data around your API in in my like training sets So I'm going to just try to use
CRL to to to talk to it and see what happens, right? Like suddenly think about like if it calls an endpoint that's wrong instead of giving it an error, can you give it context on like how should it use your API or where should it go look or what should it do, right? like every touch point becomes like an opportunity to give context >> and a completely
different question just because you know so much about the web. like what do you see in terms of like frameworks happening and [snorts] where do you see yourself uh like as netlifi much different than forcel today? Um, I don't worry so much about like the the whole software landscape is is really really open. Everybody's figuring out how to cater to that and like Brazil is one player,
but like everything is sort of up in the air. Um, how like GitHub is a big piece of what I think is not really working for people anymore. And there's like some short-term issues where they're having trouble with like capacity from the throughput, but like there's some bigger issues where the whole idea of like the workflow being centered around reading and writing code is kind of disappearing,
right? Like so I'm thinking less about any competitor to be honest. Like I'm thinking about at least like 45,000 that come to sign up where a lot of them are are a whole new kind of team like people building with like much like typical technical engineers and much more new builders. What are the tools I need to give them to give them a full software development life
cycle including like version control and environments and rollouts and roll backs but sort of separated from all of the habits we have around like a world where code is the center of our intellectual property of our work output and input and so on right like and I think we're going to see very very big shift in the landscape from that. I think the framework area is kind
of like a lot in flux as well, right? Like um Next.js ended up with like in in building a a a great developer experience, they ended up in a lot of complexity between like server and front end and so on that the models tend to struggle a bit with. And we've seen like almost every vibe coding platform adopt like V-based frameworks and simpler frameworks. Tenstack is like
is starting to get really popular, lovable, just switch to tent stack. We've been building on them and so on. But I also think that there's like this short-term moment where when you think of frameworks, they're kind of like a set of patterns um that are relevant for for for a lot of people building the same type of application. And I think right now what's happening is that
we're using these agents to build the same kind of applications that we've all built building for like the last but um but much faster. And I think that's like great, right? Like there's a lot of use for just being able to build those apps and more of them faster. But I think the next frontier is kind of figuring out what is it we can build if we
get more ambitious and say like what what can we build that we just couldn't possibly build without these LLMs and what do the frameworks for for those kind of apps need to look like and that's probably going to look very different than than than any of the frameworks we have right now. Um I wrote this little blog post um just about AI and and ambition um because
like I think in general there's so much talk about like efficiency and we can get more efficiency from these AIS and so on, right? Like but the other side of it is like if we have all of these LLMs available and all of these coding agents available that can spit out software, we can also be way more ambitious. And I had these small examples on on my
blog that like that are just more ambitious because like for my personal blog I could find time to do something like that, right? Like I integrated this little library called pretext to do justification in like latex manner and so on. And that library in itself is like one of these emerging examples of stuff that like that we just couldn't really build and maintain before LLMs. I built
this little thing where every time I write a blog post, instead of just having like an index page that like auto updates, I made a skill for like being the designer of this edition of the blog. So every time I add a blog post like plot code or codeex or whatever I use will go and redesign the whole blog like around that blog post and come up
with like use like either Gemini or GBT image 2 to come up with like cover images and stuff like that, right? Like and and I have no idea what will happen when like I publish a blog post, right? But it's kind of fun. But it's also like just like one of those small examples of things we just couldn't do without this, right? Like and that's kind of
like I'm very excited about like the democratization and the access and everybody can now build the kind of apps we've been building like that only a few people could build before. But I'm even more excited I think about like what are the next frontiers for for for what can we build on the web? What kind of software can we build that would just not be viable without
these armies of of of coding agents? Yeah, about that last question maybe or I don't know how much time we have but um yeah the if if these agents become so smart and I can just ha have my agent look at your software and and uh copy everything. Is is that something you're >> see as an issue? >> I I think yes and no, right? Like I
think there's a lot of software where where that's the case. Um then there's also a lot of things that where where it's not the case, right? Like I mean over over the last years at Netifi like ways where we've gotten more ambitious is also like saying like we have these agents now let's uh rebuild our whole compute platforms from scratch on top of like orchestrating microVMs from
the edge from the sandboxing layer to the origin layer. um let's think about like what more we can do at the networking level at the like all of these things still takes very long time to build even with agents right like so I think the smart thing to do as companies is like again you got to use the agents to be more ambitious and start building the
things that are still hard to build with agents because otherwise then yes if you just build the things that are easy to build with agents then you have very little margin capacity, right? Like if you then like then you will have these stories of getting replaced, right? Like that like Qualrix, right? Like we we used Qualrix for for our net promoter survey score in the app. And
as we started just like having this massive search in users come in, right? Like we get a call from like the Qualric Reps being like, "Oh, congrats on all the success. We should like you should have a much larger Qualrix package now because of our usage pricing, right?" like and our head of researchers just like opened an agent runner and was like built me an NPS survey
inside the app and it did that and it worked and we cancelled the qual contracts instead of growing, right? Like and and that that kind of pressure is going to be really real, right? like you you got to use agents to be way more ambitious and do stuff that's still really hard to do even with agents and keep pushing the boundaries of that if you want to
have something that's really worth charging for. >> Yeah, it it seems wonderful that anyone can now build this software so quickly also with your agent runners. But aren't you afraid being like a hosting company that there will be so much slop on your platform and how are you dealing with that? Are you going to maybe look also at engagement and turn things offline? Um, I mean, we
we've tried to align our like our pricing model with this model of like lots and lots of people building like lots and lots of smaller software and make make sure that works for us. And then we've always like when you let people publish to the web, you also kind of always have a responsibility for figuring out how you deal with the stuff that should not be there,
right? like because some people come to us with with with stuff that like we definitely don't want on our platform. So over time we've obviously built ton of automation around fraud detection, fraud mitigation and so on. And it's fortunate for us that like we build around we built a lot around identity and figuring out who is and do they look like a legitimate person. And that gave
us a lot of false positives and bad experiences from people that got like flagged by the algorithm and now had to prove that they were good. And we shifted a lot of that work to like whenever they do something like check in on like does this look good or bad and and and sort of like qualify them over time by like are they doing things that that
that are good or like have they done a lot of good things then they're probably not that bad actors versus who they are. And that works really well in this world of like agents where the whole model of like identity as the fraud mitigation and like just kind of either you block all those agents because they're bots like what happened to my open claw, right? Like or
or you give up on the whole identity layer, right? Like so we've been fortunate that we were sort of like early in in building those kind of flow that's based on like actions versus identity. Yeah, that's uh lucky that you anticipated it uh before agents were even there. Um and about the what's since so many since everyone can just [clears throat] vibe code on any platform like
what do you think will be the role for software engineers? >> I I think we'll have more software engineers. Um, we'll have way more builders in general. Um, I I think about it similarly to the like way back to the printing press, right? Like before the printing press, like reading on the one hand, just reading and writing was like a tradable skill, right? Like you could literally
have the job of being a scribe, right? Like there was like a whole profession in itself but it's a really in the big scope of things it was relatively small profession right like and then there were like noble men and priests and so on who could read and write above that and also interpret the sacred texts and so on right like and once the printing press came
along it sort of shook all of that up right like and started popularizing the idea that everybody can have books and read you can't get a job today being a scribe right? Like if you write in your CV, I can read and write. It's probably not going to work well. Um, and there's no longer that binary like you're either like in the club or outside the club.
Everybody can read and write. But I'm sure there's like a lot more people today that get paid for being professional writers than there were before the printing press, right? Like it's a really common profession now. um and you'll still have specialization even if everybody need to do some writing at work right like you you'll see that shift and I think that's what going to happen to software
as well we're going to go from this world where it really was very binary right like it really was like this club of like if you're really generous maybe like 100 million people out of like 7 billion that could read and write code right um and and where it was to some degree you could get a job just from being able to read and write code. And
that binary path is going to be away, but there's still going to be specialization. And you're still going to have people that are really great at building software versus people that use writing software as sort of a normal part of their job. >> Nice. Thank you so much for all your enlightening thoughts. And I think we're all going to go back home and make sure that we
have our agents let them play around with our own software with our own tooling and see if it's actually optimized or not. Yeah. Thanks so much for inspiring us and uh everyone give a big hand again to Matt Beman from NEPAC. >> Thank you.
