Panel Discussion: Fullstack is Eating Frontend — Should FE Engineers Adapt?

All right, well, are you all ready to kick this thing off? Let's get going. I think the easy place to go with a question like this in general would be is full stack something that frontend-specific developers should be spending their time on, or should a frontend stay as a specialty? Is there anybody who feels strongly about this? Alem. Yes. So, I started way back like 10 years ago, and I started working on Laravel, which is kind of full stack because you have to do the client and the server stuff. And I've always fought this battle with, because I later on specialized in frontend development, and I've always fought this battle with everybody that works next to me, that you should always be a generalist and understand the full system. And the reason behind that is because, for example, when you want to talk to a backend endpoint, if you know how the data should be structured and sent back, you can kind of shape the API and make it better and more performant on both sides, just by talking to the backend developer and saying, hey, what about if we group these fields together, or maybe we cache this stuff. You don't really have to understand the full system behind it, but knowing the basics was always important. And I always draw the line between doctors. Doctors also have subspecialties, and they specialize in a certain part of the body or something like that, but they're still doctors. They know how the whole body works. And I feel like developers should be the same, where we know how the whole system works, but we still specialize in something like frontend development, backend development, because everybody loves a certain part of software development. And there should be specialties, but I think we should know the whole system. Yeah. So what you're saying is developers are doctors. Yes. OK. But for software. I love that. Yes. But our software doesn't die if we make a mistake. Yes. That's great.

Kevin? I broadly agree with you, but I'm going to challenge a piece of your statement, which was, oh, they should definitely do full stack. I think we all need to expand in different directions, have a specialty. But it doesn't have to be towards backend engineering. You could expand towards an area of subject matter expertise. You could expand towards understanding design more, user research, other parts of product. I think we are ending an era where we can specialize in a particular area of technology, most of us, and still be able to have a good career. I think that technology could be your superpower that you bring, and then you navigate into other spaces. I think I might actually challenge a little bit of that.

Do it. Challenge. Yes. I think in the age of AI, specialists are more important than ever, because AI allows us to all be generalists very quickly. So I know a lot of us have probably vibe-coded something in a language that we've probably never written before. It's really easy now to get the basics faster than ever before. So I think that makes the value of being a specialist exponentially more important. Yeah, I think I agree with you, actually. I think prior to AI, you could still have this question about whether it makes sense to call yourself a frontend developer or full stack.

I started with Rails because I wanted to make full products, end-to-end. And so I was doing full stack development. Then I fell in love with client-side JavaScript and micro-interactions and animation and CSS. So now I consider myself a frontend developer, not because I can't write server code or create a full product, but just because that's where I spend most of my focus, is the specialization. And I think post-AI, it's interesting because... I don't know if you've had this experience, but if I talk to a backend person who's pretty back and they're like, I love AI, man. I always hated wrangling some React components together to build a frontend. The styling always didn't work. And now AI just does frontend code so great, I don't have to do it anymore. And I'm sitting there like, really?

For me, actually, setting up this new backend service with AWS and writing this Python... I don't have to even learn that stuff. AI does it so great, but it does a crap job at frontend code. So I think everyone's saying the same thing, which just tells me that there's still value for a specialty, right? In that if I'm doing some polish, some micro-interaction, or just really focusing on the details of some interface, I have to know what to tell AI, if it's even gonna be helpful. So yeah, I think it still makes sense to have a frontend developer designation, if that's what you're an expert in.

Yeah. But I think it's just a specialty, right? Like, AI is really good at the stuff you know little about. And less good at the stuff you know a lot about. So yeah, totally. What do you think? Yeah, I think I'm a bit of a fence sitter on this one. I started my career as a designer, frontend developer. So I think I'm kind of obligated to say that it should exist and continue to. But at the same time, with platforms like Neon and with the modern deployment platforms and deploying to Railway and having a 10-line config file to get your deployment going, there isn't really an excuse, I think, at this stage to take that on as a secondary skill, even if it's not your specialty. But I think in terms of frontend development, I think there's something special about somebody that is specialized in frontend development, that knows design, that has that specific taste and that level of awareness with different types of design systems or just when something looks good or just does not look good, that you can't always get as a generalist. Yeah. I do think we should take a shot when somebody says taste. Because I've already caught myself saying it like three times today. So I love that. You had mentioned Rails, which kind of feels like maybe even the maybe not the initial bit of people writing full stack, right? Because you had UI, you had backend, you had everything, right? Is the world now with, whether that is React Server components or the revitalization of server-side rendering coming in to everyone using it all the time for everything, are the worlds of backend and frontend inherently meshing and colliding? Forever. Well, it's funny to hear. If you look at some of DHH's early videos talking about Rails, he had to go on a crusade to convince people that it was okay for application developers to set up databases. We used to have database engineers to configure databases. They had strong opinions about what you should name your keys and your primary keys, your foreign keys, what indexes you should have, and very particular minutiae about the database. And you would have to talk to them to get your database set up and wired up with your Rails server. His whole thing was trying to compress that complexity into the framework and giving the application developer control over that. So they didn't need an engineer, but also so that they could set the database up in a way that serves the needs of their app. And in the same way that you were talking about, that's kind of how I've seen it play out in the last 10, 15 years with frontend developers, is when I started, you would have to know how to get LAMP stack running on your computer to get PHP talking to MySQL to serve. There wasn't even an SPA back then. But basically, to query your data and render something and then to make API endpoints for your SPA. And a lot of what the frameworks have tried to do is abstract more of that stuff, put it in the hands of frontend developers, application developers, really. So that today, in the same way that Rails let you not need a database engineer to set up a database, but you could do it as the app developer, today you can set up caching layers and CDNs based on the needs of your app. With cache components, for example, in Next.js, you get to choose. You as the app developer know that this screen doesn't change that much, so let's pre-render it and put it on a global CDN. And I do that from my application code. I don't go to a Varnish and learn how to write a Varnish CDN layer.

It's driven by the application. And so in that sense, I think the product developer is like the frontend is eating more of the stack and giving more control to frontend developers because of that trend. And I think with AI, AI lets you do that indirectly, I guess. You don't need an expert, but it's also feeding into this just broader trend that we've seen ever since Rails and now with more of the stack and infrastructure coming under our control.

So I'm going to push on this another way. You were kind of describing what happens when the backend developer writes some React code and they say, yeah, I can do it, so we're just going to do it. And I've reviewed those PRs. They are miserable. I think separation of concerns is still valuable. React rethought about, was the original framework that rethought about how we should separate concerns on the frontend and said, hey, it's not CSS versus JavaScript versus HTML. We should separate by component. That is extremely productive. I don't think the way that things are separated on the frontend works very well for a lot of patterns that you want to do on the backend. I have yet to see a very large nextJS application that did both that didn't make me want to pull my eyeballs out.

I'll jump in here. I think it was Brad who talked about the separation between the back of the frontend and the front of the frontend. And I really like that distinction, because I think we are starting to see almost two separate classes of frontend engineers, and there's kind of a back of the frontend engineer that is really interested in doing that kind of work and setting up server side rendering and handling all of those kind of performance issues. And then we also see a very front of the frontend engineer, which is more CSS focused and accessibility focused and design focused. And so I would almost say, you know, is full stack eating frontend? I don't know. I think frontend is actually growing, and we're seeing almost subspecializations rather than seeing it consumed entirely. Yeah. Almost like a reclassification of frontend. You called it an application developer, right? I think that's an interesting way to look at it. And Brad's point is really great with the front of the frontend. We see design engineers now, we see UX engineers now. And I would consider all of those under the umbrella of a frontend engineer probably that front of the frontend engineer. And with AI, designers are writing code. More important than ever.

And with AI, designers are writing code. More important than ever. Yes. I'll note, I'm no longer hiring frontend, because all my designers are doing my frontend. That's interesting. Yeah. Because designers inherently have a different eye and they have a really deep attention to detail. We used to hire pixel-perfect frontend UI developers who had to get and reimplement a PSD to exact specifications, right? But the designers can do the code. And it is why I'm saying things blur in many directions, right? You can spread from front to back. You could spread towards design. Now, historically, frontend developers was where the more user experience dynamic thought was, because designers weren't good at that. Their tools were static, so they were thinking about things statically. When you got into the medium, you started working with HTML, JavaScript, and CSS, you had to deal with all the corner cases and the transitions and those different things. But designers can do that now. And often, they have the eye, they have the thought for that, they can do that. And once again, if you're starting from a frontend, you can move into that space, right? You can really develop your eye and your thinking about the way that things work together. And that is just as valuable. In fact, I'd say potentially more valuable now that so many things can just be delegated to the AI. Thinking about the nuances of the experience is a huge source of alpha. The taste. Can I ask a follow-up? Because you were saying you don't hire frontend developers because the designers can code now. They can submit PRs with code with AI, right? Yep. But weren't you saying that you saw some of the frontend PRs from the backend folks? So do you think that the skills that the designers have in terms of what to look for, their experience with bad designs and good designs, and what it takes to go from a bad design to a good design is more helpful to get them to be more successful with AI? Because they know how to talk about it, to it, in a different way, and therefore they can... Even though they don't know frontend code the same way a backend engineer doesn't know code, but they're more successful getting a PR that you can actually merge. Yeah. So there's two things I've seen there. So one is, yes, I think most designers and product managers are often, they are more natural at prompting than engineers are, because they are already used to thinking about how do I translate this for an engineer to build? You think engineers are bad at communicating with other humans? When we talk about skills that we could develop, I would promote communication as one that we all should work on. But then the other factor is that designers are already used to thinking component-first in general, and decomposing things by components, where backend engineers have a different mental model of composition, and so the mental model that designers are bringing often translates into much better frontend code than when backend developers start prompting it. Yeah. Alen, you're a part of TANstack, and the TANstack ecosystem has a ton of documentation, a ton of packages, and a ton of design work.

And that's also very community-driven, right? And in those types of situations, is that the engineers who are working on those packages and projects handling the design, or are there people committing design specifically to these repos? Yeah, I think it's mostly us designing it, and some of us are better at it, some of us are worse at it. Like, for example, I personally can tell you if something looks good or bad or not, but I cannot design it to look good or bad. I just can't do it. I think naturally, I'm a very curious person, and I feel a lot of people use their titles as a security net and a security blanket, to not go explore the other sides of software development, because software development is so much more than backend development and frontend development, design, whatever. It has so many sub-specialties, and I think exploring all of them and learning about those things helps you in your specialty as well. Because for example, I learned design, and this was way back in the day, material design and stuff like that, and then after I learned these concepts and how the designers think, it really helped me shape some of the stuff I was working on, and then add changes to some features without asking the designers, because I know how user experience works. And then I can apply some of the concepts I learned about user experience to the feature and make it better. For example, the designer creates a flow that requires three buttons. I know from user experience it's better to have one button. I figure out a way to create only one button to get the user to where he wants to go. And I think it's really important to be very curious and explore other specialties, because that's how you improve your specialty as well.

Yeah, I love that. Ryan, did you have any thoughts? I think if you take React to its logical conclusion at this point, if you look at it in terms of the question, it's kind of just empowering frontend developers. So while the mental model might be a little difficult to get your head around at first, but with server components and server functions and that sort of thing, it really do kind of give frontend developers additional tools that make things a bit easier in the long run. So pairing it with things like Neon, like I said earlier, and different kind of GUI tools that make some of the backend easier, it just kind of makes sense that it would stay around. Yeah, yeah, absolutely. And we touched a little bit about this, and it's come up a couple of times. What is AI good at in here? And I think to have a non-controversial question here, is AI better at frontend code or backend code? AI is too monolithic. I would say that most of the anthropic models are pretty good at frontend code. They're not very good at a lot of backend code. If you ask GPT-5 to build you a frontend, you will regret it. But it's pretty darn good at writing at least the world I'm in, Golang backend code. I think it depends a lot. Most unsatisfying answer ever. But on the Next scene, we started bundling our docs with your app, and have a small agents file so that if you are prompting, you know, an LLM on your app, it says, like, ignore your training data and treat the bundled docs as a source of truth. And that made it perform way, way better. So does it do better at frontend code or backend code? Well, if you're using a library, a framework, that's documented well, and it knows where to find those docs, they've gotten to the point where they'll do fantastic. If you're just asking a generic model, it might give you an average response based on all its training data. And again, the more you know about something, the more you're likely to see that and be like, this is wrong. You know, it's like Stack Overflow, for those of you who remember.

You would ask a question on Stack Overflow, what would happen? You would see like the most upvoted answer with a check at the top, and then you'd be like, that's wrong, I need to scroll down and see the one with actually the most upvotes, but that wasn't marked correct, and that is always the right answer. So you have to know to do that. But that's kind of how I think of the generic, you know, unguided AI. But I think it does really well with good docs, you know?

Yeah, I think that's kind of the ticket. I find, and I think we've all kind of experienced this at this point, if you're not heavily steering it or providing docs, you're going to get kind of that dreaded purple effect. And so I think that yeah, good design system ahead of time, which, you know, you don't necessarily need, I guess, a front end developer for, but you probably should for something like that, as a guiding principle, is crucial in using AI for front end. Yeah. It's funny, actually, I had an issue where Codex specifically was adding a bunch of gradients, and I said, why are you adding gradients to all of this? And it says, you told me to. And I said, I absolutely did not. And then it outputted a system prompt that says, add expressive gradients to make it not feel flat. Like, what? I think AI is always going to be as good as the person prompting and iterating with it, right?

So if you are a front end developer working with AI, you're going to get strong front end code. If you're a backend developer working with AI, you're going to get good backend code. If you're a designer working with AI, you're going to get better design results. So I mean, maybe if you're looking at the raw results of the model after a one shot prompt, there's a difference. But that's not actually how people are working. So I would say it's almost unimportant. Yeah. So as you said earlier, I'm the maintainer of TenStack AI and DevTools, and I've been doing a lot of marketing for our organization. And I've been using both GPT and Opus as testing beds, and I would prompt them the same question. And Opus does so much better work with creative stuff than GPT. GPT is so sterile and boring, and I tried to create a presentation for the conference, and it just wrote a wall of text on every slide and like 50 or some random boxes. And I was like, who is this for? And then I asked Opus, hey, can you do this? And it drew some fun diagrams. It kind of added some fun stuff. And I was like, okay, this is actually usable instead of GPT. So I think it depends on that a lot. And another thing it depends on is using skills and stuff. For example, I've been begging Tenor to put a branding guideline skill just so I can feed it to an LLM and tell it, okay, please use TenStack AI pink color and don't use red and yellow every time. And that's the gist of it. It is well worth experimenting with the models. And you can play with Kimi and Composer and these other things.

Composer is pretty good at CSS, shockingly. But they do have differences. To your point, if you have a really good brand guideline, you'll follow that well. If you're trying to do something new and interesting, don't use GPT. But also, if you're trying to write complex, knotty backend code, Opus will write it five times and start editing other files. So they all have their strengths.

Yeah, I was just gonna follow up. Yeah, what Catherine said, I think it's as good as the person using it. Another way to say that is I think how you should think about AI is as a complement, not a substitute. So it's a tool. It complements your skill set, what you're trying to achieve. It doesn't substitute it. And it's always been the same, even before AI.

So again, back to the Rails analogy, Rails let you set up databases from your Rails code. But that doesn't mean you didn't need to understand what a database was or how to model your data or set up relationships, or what a join table was for a many-to-many relationship. In fact, Rails empowered backend developers to learn about database design. And it made it worth it to learn about database design because now they could configure and set up a database for their needs without having to learn how to actually set up a MySQL server and all of the minutiae that an actual database engineer would need to understand.

So similarly with the frontend stuff, whether it's Neon, like a cloud service for a backend, or Vercel and Next's example of letting the frontend developer set up CDN and caching, you have to understand caching, you have to learn principles about it. And so I think it's the same with AI, where it's so tempting, and especially I think when the models first came out and got good enough that you can just prompt something and you have something working, you're like, wow, I don't actually have to use my brain anymore. People are like, we're saying that. Like, I don't even have to think anymore. No, you still have to think. And so it's exciting that it can do that stuff in one shot, but like the prompt of the panel is should frontend engineers adapt? I think a frontend engineer should learn, and still, if you find yourself motivated and you're inspired to take on some new part of the stack that you haven't before and you start using AI to do it, that's awesome, but you should still learn the first principles. You should be a first principles thinker, and use AI to help teach you those first principles, and then use it to speed up your understanding of the first principles, but then also the actual implementation. I mean, it's great at doing the boring work, but you still have to understand the first principles of whatever you're doing.

The biggest differentiator I've seen between people who thrive with AI is they add one question at the end, after they get it to do something, they say, okay, why did you do that? Yeah. Okay, well, you actually got into the very next question, which I think is really great. So I don't know if people realize this, but the year is almost halfway over. 2026 is almost halfway over, and so as the new models come out, we just had Fable and Mythos just came out. All these things are changing at rapid speed. How do front-end developers adapt for the year going forward to this change? Big question. I think it's all about curiosity and learning, and that's it. Because, for example, when I started with TensorStack AI, I just wanted to build it, and it's a back-end oriented tech, and I'm a front-end engineer by heart, and that's my passion and that's where I've been for a very long time, and I had to learn so many back-end concepts and figure so many things out, and it was all worth it in the end because now I feel so comfortable with it, and it's super fun to build all of these new experiences for people who are using TensorStack AI and for myself as well because you create all of these super complex systems and you make them easy because you understand them, and you just create some super advanced flows with AI, like, hey, do this workflow, create this, then call this agent, then do this and that, and it's super fun to do, and I think people can just explore. For example, AI was the next big thing for me to learn, and I'll probably have another thing in a year or two that I want to learn again.

So I think it's all about learning and improving yourself and making yourself a better developer because it's not an industry where you're like, okay, I have learned X, Y, and Z, I'm done with learning. That's it, I'm done forever. You constantly have to learn and improve yourself. In the front end, we should be used to that, right? Who remembers the framework wars? It felt the same. It's like, there's something new every week, there's something to keep up with. You don't need to know it all. I did a talk on that, and I listed out all of the changes from floats to now, and I was out of breath. I was actually exhausted from talking about it. It is exhausting, and it feels like that now, except it's everybody all at once, but that is kind of the new normal. Things are changing all the time, so one, yes, maintain curiosity, keep learning, but two, don't feel like there's a place you're going to get to and be done, which is also in some ways freeing, because it means it's not that I'm behind, everyone's behind. There's no there to get to. What do you need to do your job? Figure out that much, do your job. Don't feel like this pressure that, I always have to do more and more and more and more and more, because there's nowhere to get to.

There's no done. Yeah, I think to kind of harken back to the first principle's point, you either have that curiosity, or you don't, and if you do have that curiosity and you like figuring out how things work, and you want to expand your skill sets, I think using AI as a superpower to learn the different concepts that maybe you're lacking, or just to explore different things that maybe might not expand your horizon on the job market, but it might just keep your interest in computing and in building apps in general, and expanding your design sense as well.

I think, yeah, using it as a superpower to kind of just supplement your curiosity and your learning is super important to adapt in the coming year. I think there can also be a false feeling of rush around this that I would push back on as well. As everybody likes to tell me, this is here and it's not going anywhere, get used to it. So you have time, is the flip side of that. It's not going anywhere. And if it's not relevant to what you're doing today, it's okay to pick it up tomorrow, or a month from now, or three months from now. The technology will move. The technology has always kept moving, and there's always been a new entry point, and I don't think that's ever going to change.

Do you remember the alternatives to TypeScript? Oh, CoffeeScript? All of the alternatives. There's so many of them. I'm still burned by the lack of a turner in CoffeeSick. Yes, so things change, right? Yes, you can pick things up, you can wait. Sometimes it makes sense to wait, sometimes it's a better strategy to wait, because in the TypeScript versus Flow, or Reason, or whatever case, it's the same with CoffeeScript. CoffeeScript back in the day wasn't much about types, it was more about syntax and primitives and stuff to make the language nicer to write, because ES4, ES5 wasn't moving much, and it was just painful.

People discovered compilers, and they started making their own languages, but CoffeeScript wasn't like a superset of the language, and once ECMAScript started adding nice features like async await, and arrow functions, and object destructuring, those weren't backwards compatible with CoffeeScript, so you had to rewrite your CoffeeScript code. That specific knowledge didn't transfer. It wasn't general knowledge that was leveling you up on your thinking, or your principles, or your understanding of fundamentals, it was specific knowledge. It's fine, it's not like it was a problem if you did that, but it didn't carry forward.

I think a lot of that way about AI, like Fable just came out, I haven't used it. I'm a late adopter. I didn't really start using agents until Opus 4.5 came out or whatever. I feel really strongly that all the time I invested in Flash is going to come back. I think that's going to work out for me. The models keep changing, and they keep learning new things themselves. If there's somebody who tweets about some tool that's going to change your life, and then the model can actually do it in a week or a month, then you don't have to worry about people telling you you're missing out. You can just wait and learn the fundamentals.

I think there are fundamentals that you can learn for working with AI, better versus worse, and it doesn't involve keeping up with a news feed full of hyped material, or new tools, or new workflows. Those meta skills, curiosity, how do you learn better, how do you communicate better, those are going to keep being valuable no matter what AI does. The best thing about models getting smarter is that you can use them to learn new things. For example, the other day I was working on AI workflows for TensorStack AI, and I have zero knowledge on workflows and how they usually work. I was like, okay, I need to figure this out. What I did first was write a skill that's going to generate a mini course for me, based on my previous knowledge. I wrote that skill, and then it asked me, what's your experience, what's your background, I thought I'm a front-end engineer, I know Legos and stuff. Then it handcrafted a course using analogies from Legos and front-end development to teach me workflows.

That's how I used an agent to teach myself workflows, which I had no idea on. Now I'm proficient at it, I'm not an expert, but I know enough to get the job done that I need to do. Yeah, it does feel like these tools are underutilized for learning, adapting to your own specific way that you consume knowledge.

Actually, in my talk I had to do a Q&A up here, right? As we do. I fed it the slides and I said, grill me as if you're an audience who's out for blood. I want to be prepared for these questions. It was great, because it allowed me to dive into some of the APIs deeper and explore my brain in a different way. I love this message that learning it for learning is such an important thing.

Well, and what you were saying, right? There's so much hype about, I don't have to think, I'm going to delegate my thinking. If you're delegating your thinking, you're using it wrong. Figure out how to use it to elevate your thinking. Oh, that's a good note. Yeah. Let me get some snaps for that. Yes. So, okay. Given all of that, I love this message of being slow to wait on things, but how do you know when something is ready to jump on? When you need it for the thing that you're building. When your boss tells you to do it.

Yeah. Motivated learning, right? I mean, it should be motivated. Not only does that give you enough context for the problem that the thing you're reaching for will solve, which helps you understand why it was created in the first place. Again, this applies to libraries and frameworks too, the same as it does AI. It's just going to be more interesting. You're going to naturally want to understand it at, again, like a first principles level.

So yeah, if somebody is happy with how they're working and what they're doing, they shouldn't use AI. It's kind of controversial to say, honestly. I do think it's worth building the muscle of asking it. Building the muscle of, what else should I think about with this? How would you do this? Asking the LLMs, because I'm just shocked reliably at how much it's able to teach me or show me or say, hey, you should go read this. You should read that. You should check this. Just to follow real quick. I started using agents heavily when Opus came out because that's when like everybody was like, this is a real step change.

It's pretty awesome. Like it's incredible, but like there was two years of people making Ralph loops and all sorts of stuff. I didn't have to do that. I didn't really was not super interested in a lot of that stuff, but it's pretty obvious when there's a big step change, but you get to pass by a lot of stuff if you don't want to- You don't jump on every- You don't jump on everything. Yeah. I'm not 20 years old anymore. I'm tinkering with everything that I see on Twitter. I was just going to say it's super convenient and usually the first step to resort to agent mode, but I think going from first principles and wanting to further your learning, it is sometimes a lot better to just go to chat mode and figure it out on your own and use your brain to learn the concept rather than just having an agent spit it out for you. Yes. A great note to end on is to use your brain. Thank you so much- It's a novel concept. ... to all of the panelists here.