How I Build Web Applications in 2026

Hello, everybody. My name is Kent C. Dodds, and I am thrilled to be here talking with you all about AI. My talk is titled How I Build Web Applications in 2026. And actually, it is just the beginning of 2026, so how do I know? Well, maybe I should retitle this to How I Will Build Web Applications in 2026. But for the last over a decade, for those of you who know me, I've been teaching people how to build quality web applications. It's just what I enjoy doing.

So what does this have to do with AI? Well, everything has to do with AI these days, and building web applications is no different. So while we may have changed the way that we build software, and I'm going to show you some of the things that I do now, the ultimate goal is still the same. We still want to deliver excellent user experiences for our users on the web. And so I'm going to just talk about some of the things that I have been doing that help me deliver excellent user experiences faster. So let's jump into it.

First, I want to tell a little bit of a story. So I have a set of workshop series, Epic React, Epic Web, Epic AI, Testing JavaScript. And the more recent of these, the recent versions, are using a project that I call the Epic Shop or the Epic Workshop app. In the old version of the Workshop app and the old version of Epic React, you were actually able to download videos for watching them offline. In version 2 of Epic React, we lost that ability. And so here's one person who was lamenting that they wanted to be able to download the course videos for offline work. Perfectly reasonable suggestion. And I just that wasn't really a feature. And with the nature of the Workshop app, it was actually a lot more on me to do that and provide that experience. The original Epic React, it was literally just like, download these and here you've got a bucket full of files. Good luck organizing them yourselves.

But with the Epic Workshop app, the videos are right in line with the rest of everything. If you've never gone through an Epic Workshop, you really should. And there's free ones too, so you can get a feel for the experience. It's fabulous. But yeah, so this user was just, or learner was lamenting the fact that they can't do that. And I saw this issue and I'm like, yes, I've been thinking about this. It's just a massive amount of work.

So this was back in 2025. Our AI was really good back then too, but things have really changed in just the last couple of months. And so I was able just a couple of weeks ago to build out this feature. So now it's available. This person is very excited about it. And now everybody who's like the tens of thousands of people who are going through Epic Workshop apps can now download the videos for offline use, which is quite nice.

So here's just a quick demo of what that looks like. So this is the workshop app. We're on a particular exercise here for the MCP Workshop. And here I hit the download button and it downloads. And you can actually also go to your preferences to download them all. So we'll take a look at that. But yeah, so now this is all downloading offline. The experience doesn't really change a whole lot. And then you can delete it to save space. And now you can watch it as it's being streamed from the internet. So that's the basic feature, but we also have the ability to download all of the videos all at once so that you don't have to go through and download each individual one.

It is a lot. And there's also a feature to control what your default quality is. So if you're fine having a lower quality so that you can save some space, you can do that really easily. So the interesting thing about this is that this was a really significant amount of work that I accomplished three weeks ago, but I didn't do it.

Yes, it's 2,000 lines, 2,300 lines of code, but I didn't write that code. It was actually an AI agent that did it. And of course, this is no big reveal. You all are using agents in your software development now. My preferred is Cursor. I've been using Cursor for a long time, and it's fabulous. But whether you're using Cursor or Cloud or Codex or whatever, the principles that I want to talk with you about and how I develop software will definitely apply to what you're doing.

This was a really huge moment for me. I'd been playing around with a lot of things, but the models had just gotten so, so good that it really changed my workflow. Let's talk a little bit about this. You are now an AI agent manager. You are a manager of computer things, of these agents. I know lots of us individual contributors for a long time, we just don't want to bother with managing people or whatever. We don't want to be in management. We just like writing the software.

And you can continue to do that in the same way that you still see a horse and buggy on the streets of New York. You don't see a lot of them, but they're a fun novelty. So if you want to be the fun novelty, then yeah, go ahead and just continue writing the code yourself. But there's so much more efficiency, and frankly, it's so much more fun. For me personally, I've had the most amount of fun controlling all these agents. We're looking at a screenshot of just like two weeks worth of agents. And these are just the cloud agents that I'm using on Cursor, and we'll talk about that.

Just throwing agents all over the place. It's awesome. And the tools are getting really, really good. So we're AI agent managers. But what does that mean? How do you be an effective manager? Well, let's first talk about what agents are. The way that I like to think about agents is that they're junior teammates, infinite stamina, and zero context. And if you've ever been a team lead before, had a junior on the team, you know the sorts of things that you can do to make them as efficient and successful as possible. And those are the same sorts of activities that you need to do to make an agent really successful, managing that context and all of that stuff. We're going to talk about that too.

So for those uninitiated, here is my definition of an agent. And I posted something similar to this on X. And most people seem to agree that this is a pretty good mental model for what an agent is. In fact, I posted a simpler version of this, and somebody gave me an even better one. So here we have our initial context. Initially, we're not done with the task. And then while the task is still not done, we're going to pass context into an LLM. We'll get context back and whether or not we're finished. And when we're done, then we exit the loop. And that's the agentic loop. Now, of course, there's a lot going on in that LLM function. Those are generating, doing inference and doing tool calling and stuff like that. So this is oversimplification, of course. But the thing I want to call out here is that context piece.

That's the responsibility of your harness. So that would be either your cursor or your VS code or your cloud code, whatever, and the prompts that you write. And that's really what we've been focused on a lot, is that initial context, that initial prompt. If we can get that right, then the agent is going to be solid, and we're going to get our one shot of a billion-dollar app idea and make no mistakes, right? I actually think that this is maybe the wrong focus. Our workflows need to change from prompting to agent loop optimizing. So that context is really important. But I don't think that prompting is really the thing that's going to make you the most effective AI agent manager. It's managing the agent loop.

So coming back to this, you're managing this. How does it know that it's all done? That is your job as an AI agent manager. If you think about a manager for people, that honestly is the primary job of a manager of a team of developers as well, is how do they know when they've actually accomplished the task? Do they understand the task well? There's a lot of nuance to this. This gives you the right mental model to think about and frame some of the tips and advice I'm going to give through the rest of this time together.

This is Cursor. I've got the browser mode up on the right. We'll talk about that in a little bit. And I've got the agent in the middle and then my list of agents here on the left. I bootstrapped this app using a project that I just created called Epic Flare. This is like the Epic Stack, just built for Remix 3 and CloudFlare. Probably the biggest waste of time that you could do, or biggest waste of tokens, is to use the agent to scaffold and generate the project from scratch. It's just there are so many things that actually don't matter in architectural decisions, and it's going to just take you a lot of time. There are some really great tools out there. I'm not a PHP guy. But if I were, Laravel would just kill this so, so well because they have this starting point. Ruby on Rails is the same. Those conventions make a really, really big impact.

But there are some really great tools out there. And frankly, I'm not a PHP guy. But if I were, Laravel would just kill this so, so well because they have this starting point. So Ruby on Rails is the same. And those conventions make a really, really big impact. So I'm building my own because I just really like TypeScript. I really like Cloudflare. And I really like Remix 3. It's not released yet. So we're still waiting on that, but really, really excited about that. And so I'm building out this so that new apps that I start can have the architecture already created for them. We're going to talk about that a little bit as well.

So when you're starting a new project, my first tip for you is like whether it's an existing project that you're onboarding into, or you bootstrapped a project and you're about ready to get going. Talk to the agent. Use Ask Mode. I don't know what that is in other agents. Like I said, I'm focused on Cursor. But there's got to be a way to just ask the agent, tell me about the architecture of this application. Help me understand it. Ask it questions about it to onboard yourself. I don't think that people talk to the agent enough. Just ask questions. Don't tell it to do stuff. Just ask it. And that's what the Ask Mode in Cursor is all about. It's very, very helpful.

And then you want the agent to ask you questions. So you're going to do something. You could just come up with a plan all on your own. But what if instead you say, hey, agent, I need to add this feature.

Or in this case, we're going to build an app called Home Energy that allows you to input the different home appliances that you have and how many watts they are rated for. And then it'll give you an estimate on how much energy you can expect your home to be using. It's like an estimate, of course. This is a problem that I'm currently experiencing. So that's why I want to know, OK, what is using so much energy in my house?

So, but yeah, this is the tip right here. Ask the agent to ask you questions rather than trying to like, here's the plan. I just wrote the whole document. Say, please ask me questions one at a time. This is also important. One at a time. In fact, I got, yeah, underlined it. One at a time, because the agent's questions will actually improve as it's answering those.

Lots of times if you say, please ask me questions, I'll just be like, here's 30 questions. And some of them are irrelevant. And if the agent just asks one at a time, it wouldn't even ask those. So I say, ask me one at a time. What are what the plans are for the app? You need to know so that we can create tasks for building out an MVP or building out this feature or fixing this bug or whatever. I don't always do this with things that are like pretty well defined or whatever. But yeah, if I've got a big project ahead of me, absolutely. Talking back and forth to agent, make sure that it understands, make sure that I'm covering all of my bases and the way that I'm thinking about the problem.

So then we want to keep the agent properly scoped. So I went through, answered a bunch of questions and the agent started asking you really specific implementation detail things. And with an MVP, and especially with today's abilities of our agents, it's really easy to change stuff. And so I just said, yeah, whatever you think is simple is fine. We can make adjustments. Don't get too far in the implementation details. Let's just focus on higher-level stuff and I'll take your judgment. So scope your agent as you're asking these kinds of questions as well and preparing the plan.

Okay, so I switched it over to agent mode and I say, hey, go ahead and create the task. So that's what this is. Now we're in agent mode. The agent will actually do stuff now, beyond just asking questions going back and forth. So that is a very intentional, like, let's talk first and now let's take action. It created four tasks based off of the conversation that we had. And I told it, hey, I want it to be like really clear acceptance criteria, talk about testing and all of that to make sure that when we're making a plan to accomplish these tasks, we're including all of those important things. We'll talk about those here in a bit, too.

So, oh yeah, that's the bottom. I'm like hitting the down arrow and nothing's happening. That's because I gotta move over. All right, so now we're gonna plan. So I open up a brand new agent. So get rid of all that extra context that is irrelevant to this first task. Honestly, that's part of the purpose of doing that overarching planning in a separate agent in the first place is to say, okay, I want you to search around the code base, understand this code base, like gather all the context you need, then give me a basic plan or a task, and then start a new agent. Your job is this task. You don't have the context from all the other stuff. You just have this chunk of context that is relevant to you. Please make a plan to implement that task. And here, this is in plan mode now. Plan mode in cursor, and this is common in other agents, tells the agent to ask questions. So it's gonna look at the context that you give it, and from there, it went through and looked through the code base as well to gather more information about it so it would know the right questions to ask.

And so then it comes back to me and it says, here are a couple of questions. This is where your experience as a software developer really pans out. And this is why I think that we're actually still safe as software developers. Who knows how good the models get in the future and how good the tools get? But right now, if I were to hand an agent like Cloud Code or cursor over to a non-technical person, they wouldn't be very successful with it. So until that day comes, your experience as a software developer is still highly, highly valuable. And so knowing the right questions to ask, knowing how to communicate with the agent, really, really important.

So here, we're going to make a plan. It's asking me some questions. I go through and answer. You can switch from plan mode back to ask mode. If it's asking you a question, you're like, I actually don't know. What do you think? And you can kind of go back and forth. And ultimately, when you're all happy with all the questions that it's asked and everything, it's going to give you a plan. You, with your experience as a software developer, can review that plan and make sure that it's doing what you expect it to do. And you can actually iterate with the agent on that as well. Like, oh, you know what? I don't want it to store watts. I actually want it to store amps or whatever. You can control that from a product perspective, as well as even the implementations perspective, which is why your experience is so valuable.

And then here, this is where the agent loop, closing that agent loop becomes really helpful. And it becomes even more helpful later, we'll talk about. Here, I'm saying iterate with the tests and your implementation until they're passing. And it failed the first time. And I said, no, no, no. What I'm saying here is, keep on going until it's passing. That is the agent loop. You set it off, and then you can go work on something else. And that is where these agents become really, really helpful and impactful. When it's done, you can go ahead and review. And so in a cursor, you have the review changes.

And so in a cursor, you have the review changes. You look through everything. You'll notice here, the test is actually using some syntax you might not be very familiar with. This is relatively new syntax in JavaScript, but it's a better way to do a before each and an after each in tests. And the only way that the agent knew to do that is because I have it all documented here inside of the agent's docs, which is referenced in the agent's MD file. So having documentation all spelled out here really nicely, whether that be skills or agent's MD with references to other documentation files, really important on not only closing that loop and helping the agent know the right direction to go and how to keep tests simple and whatever, but it also helps you maintain control so you don't have to spend as much time reviewing it to make sure that it's working the way that you want it to work.

And then you can actually make the agent do a review of those changes as well. And so I typically like to have the review agent and the actual agent do a couple iterations. So build it out, test it nicely, and then have the agent review it, iterate on each one of these steps. And only when all that's done, then I'm going to go and review it with my time. This is really, really powerful and a really nice workflow. And it allows you to send them off to do their thing, and then you can go off to do yours.

OK, so now we've got manual testing. It's a really cool thing here. So on this task, we're actually building out UI. When I'm developing, I'm going to be doing automated tests, of course, but I also want to make sure the user experience looks nice and everything. And so with manual testing, you can actually have it open up the dev server. It's running the dev server itself. It figured out how to do that, or that's documented. And then it opens up an actual browser, and the cursor is controlling the browser. You can watch it happen, or you don't watch it happen. But it can actually use that experience. And what's interesting is when I was doing this, it was having trouble with the automated tests. And so I said, OK, OK, stop, stop. Try and figure out what's wrong by actually running things manually. And then you can do the automated test. And it worked. It went through this, and like, oh, now I know what's going on. And it was able to figure out the problem.

And it was able to figure out the problem. And then another huge tip, something that I do all the time, is now I want to do MCP tools for this. I want this app to work in chat GPT. And so here I'm telling the agent to learn from examples, because MCP is still a relatively new thing. The best practices aren't really established very well yet. But I happen to know that Adam over here has some really high-quality MCP servers. And so here I'm telling the agent to go and clone those repos, figure out what is similar about those things to determine what are some really good practices, proven practices in these repos, and add that to our task, so that when we go through to plan it, we have some guidance on a good way to build out MCP servers, which is awesome.

The other thing that helped out here is EpicFlare already had MCP tools and OAuth flow already implemented, which is why that architecture is so critical. To have that in place, the agent's a lot more powerful if that's all done. And of course, I used an agent to build that out too. But I'm saying you typically want to have that piece done, and then you can start adding features to it, just like with a human too. It's a lot easier to chunk that work up. And then cursor.com agents. This is my addiction. I go to sleep with this. But yeah, so you can kick off any number of things. Like run a security audit, run an accessibility audit, like update the remit to describe what's going on in here.

Like anything that I think, oh, this is a really simple thing, just one sentence prompt, and the agent will run in the cloud, and it will open a PR when it's done. And it's really, really good. In fact, when I did that mux download video thing, and that offline video, I actually used a background agent for that. I used a cloud agent for that. And it worked amazingly well. And the really cool thing about this is that Cursor also has BugBot. You have other tools as well, like CodeRabbit and stuff that will review. And with Cursor, when the BugBot shows up and hears a bunch of things that are wrong, the agent will actually automatically pick those up and make adjustments. And then they'll go back and forth. It does seem to stop eventually, but it really goes back and forth a lot to avoid it getting out of control. But by the time I finally look at it, the agent is good with it, BugBot is good with it, and the tests, like validation, all that stuff is passing. And so what I'm reviewing is some solid code. I can pull it down and test it out myself.

If it's a really big UI change, I want to experience that user experience. But it's a great place to start. And even simple prompts can get you here in some cases, where you're just like, here's the bug, when I do this and that and that, then it fails. So write me a test that reproduces that problem and then implement it. And that's that agent loop that you're working on.

BugBot is fabulous. And yeah, this is dangerous input. I sometimes will stay up really late just prompting, and then I'll go to sleep. And first thing in the morning, I'll grab my phone and look, what did it do? So be careful with that. But anyway, my point here is that closing the agent loop is even more important in those situations where it's running off your machine. You can look at what's going on and see the threat and everything. But typically, it's just running on its own. And so having really great documentation, really good tests, and a clear, here's what the outcome is supposed to look like. That is super, super important.

Back to this, I almost finished here. I actually want to talk a little bit about that initial context. So a lot of people will say that the architecture is more important than prompting. And actually, that's probably what you're getting from this talk, is that I'm saying architecture is more important than prompting. Having a really good starting place, it makes it a lot easier for you to just say, add a test for this. And like it has that all set out, so it knows what to do. Or add authentication with Google. Okay, it's got all of that structure there. I actually don't think the architecture is necessarily better than prompting. I actually think the architecture is prompting. The architecture is a part of the prompt. And if you can document things well enough, and I use the agent to keep that documentation up to date, and you can have things set in a good architecture from the experience that you have as a software developer, then the agent uses that as part of its input context to go off and do what it's doing. So the architecture is part of the prompt. And the prompt is really, really critical along with that agent loop. So you are now a project manager, product manager, and a team lead.

So you are now a project manager, product manager, and a team lead. I don't know if you wanted to be that, but you are. You are an AI agent manager. Then like all of those roles is an AI agent manager. And your management effectiveness is measured by your experience. And that's what I want to teach you. I want to teach you how to be an experienced, full stack software developer that is able to direct and orchestrate a bunch of AI agents.

We've got a lot of really exciting things coming down the line with tooling, getting better and everything. But your ability to convert the user experience that's needed into an actual product is more important than ever. And if you feel like that's important for you, then join my mailing list. And I've got some exciting things I'm working on for that.

With that, thank you very much. I appreciate your time and look forward to seeing you around the Internet.