DN #19: Vibe Coding Slop, Full-Stack Designers & Distribution as Product (w/ Jacob Counsell)

Niklas:Hi and huge welcome to you my lovely listener. So glad you're here. Today you're joining me for a chat with Jake. Jake has spent 15 years as a product designer in SV Tech and just launched LoungeChair.io. Jake, so lovely to have you. It's interesting. I also noticed that we are switching, I've seen a lot of design systems and I would also agree that internet or websites look a lot alike these days. So what do you think if you look back at examples that were really outstanding back in the day, what was really nice?

Jacob Counsell:How's it going? Nice to be here. Nice to do the podcast with you. Yeah, I I don't have any like top of mind, but I do remember like 2010, 2012, like things were rough, obviously, and like visual design wasn't like stellar. But I would say the internet was a lot more fun and there was a lot of like, I don't know, like there was a lot of apps where you could tell people were really obsessed with the micro interactions and like.

Niklas:so lovely to have you. Lounge chair, how did you get started with that? I think that's the latest one. You have done a lot of things before, right?

Jacob Counsell:Yeah, I've personally launched quite a few like personal projects ⁓ in the past, mostly like non revenue products, just because I just like building things and you know, was obviously working like full time with ⁓ larger startups and SaaS companies. But yeah, so Launch Chair, ⁓ I kind of just, I noticed that there's a, a kind of a gap in skill set for a lot of people that are vibe coding. ⁓ And also I just, feel like it's a, know, animation and iconography and stuff. And there's a lot of like hand spun work. And it definitely seems like since we've, we've kind of like focused more on HCI design that a lot of like these, these whimsical, like beautiful, like sometimes fun micro interactions have kind of been like, you know, thrown to the wayside. ⁓ So I've definitely noticed that. And I also, will say that a new dawn for agentic coding. I think that there's a lot of people that want to get into it that have no idea how to start. I think that there's a lot of people that probably really struggle with planning and specing and scoping projects. And I think there's a lot of people that are building a lot of slop. And that's purely a factor of using tools like lovable and bolts and base 44. You know, with HCI design, it's funny seeing AI come into the fray now ⁓ because AI kind of does a lot of the work that those designers have been doing. Right, so like I've worked with a lot of people over the past like five years who will admit that they're, you know, strong, they're not strongest when it comes to visual design. They're not strongest when it comes to iconography. They're not strongest when it comes to micro interactions. And now they're using AI to do all the stuff that they are strong at. So it's, it's a little interesting to me. Like for me personally, I feel like AI kind of frees me up, frees a lot of that like UX research up, frees a lot of that like. So I just, I thought that there'd be a good way to kind of like wedge in some actual product knowledge and kind of help people build things quicker and build better products and actually focus on what they're building and not focus on, you know, an endless array of prompts within Lovable.

Niklas:Interesting. And also what I heard is that you are technical as well as a product designer. I think that's a really nice combination of being able to build things on the one hand and liking to build things, but on the other side, on the product design. How do you think this helps you? It's a unique skill that helps.

Jacob Counsell:know, mundane like wireframing and prototyping, like it kind of takes a lot of that time away from me. So I can spend more time on micro interactions and like building better product and like making products that feel fun and feel good to use and are easy to use. Right. Yeah, interestingly enough, I've been into code and tech stuff since I was probably like 10. I'm 40 now. And I was very enamored with an old website called GeoCities when I was like 10 years old. And I just thought it was really cool how expressive people could be and how there was just this huge list of just

Niklas:Yeah, I think it's changed so much, right? And for me, it's also like I've like you, I've built software since I was 12, I think. So in the beginning, I always saw that building the product was the hard part. These days, would say like scaling it and the things that come after are probably at least as hard, if not even harder. So you need to make something people want, but people also need to see it.

Jacob Counsell:bad and good websites on GeoCities. it's kind of like all I was able to think about when I was young. then because of that, I learned how to code pretty young. And I actually by like 12 was doing a bunch of like real estate websites for like my mother and for a bunch of like random people in my little city. And yeah, from there, I kind of just kept playing with code. But at my core, I'm creative and I've been doing like art my entire life. So I actually went to art school.

Niklas:I feel that this is a shift at least that I'm seeing that the focus goes more on that side. You have seen products go from zero to a huge annual recurring revenue and exits. If you look at them, what patterns did you notice in the ones that succeeded versus the ones that quietly died over time?

Jacob Counsell:Yeah, so I mean, to touch on what you were saying, like distribution is a nightmare for everybody. But one thing that I do notice is that like, if you look around on like LinkedIn and X and Reddit, a lot of the people that are complaining about distribution, it's not really a distribution problem. It's like secretly a product problem. And it's just much easier to blame distribution, right? Like you can have the best distribution funnels in the world. And if you have a bad product or I went to two different art schools and then kind of started in interactive design and agency side and then moved into product design, UI, UX. ⁓ my last full-time role, I was a principal product designer at a large legal tech company. ⁓ But yeah, so I'm full stack and then also a product designer.

Niklas:It has changed a lot, right? Like if I look at product design a year ago versus today, I think it's a different world because you have these AI tools that make prototyping also in Figma or tools like that extremely fast and easy. What do you think is the largest advantage that you have now?

Jacob Counsell:you know, an idea that is in a saturated market with a ton of competitors, no distribution is going to save you or save your product, right? So I think it's just much easier for people to like blame distribution than it is to like reflect and say like, ⁓ I built a product that nobody needs or I built a product that solves a nice to have, right? And as far as like companies that I've worked for that have, you know, scaled massively and ⁓ built like large amounts of ARR very quickly. So, I mean, I definitely see it as a double-edged sword. You know, one thing that I noticed change quite drastically in Silicon Valley in like 2015 was we stopped hiring, like we stopped hiring weirdos from art school and kind of shifted towards hiring HCI people. And that's, you know, nothing negative towards HCI designers, but I did notice that Unfortunately, a lot of it is money, right? A lot of it is like having inside connections too. Like ⁓ for example, like if you have, you know, a person that you know at Product Hunter, a person that you know at Twitter ⁓ X, right? Or a person, you know, at LinkedIn that can kind of like... Because of that, the internet immediately became a little bit stale. And a lot of product designers were kind of favoring over-indexing on design systems. I mean, it's not this way anymore, but I know that like for a while there, if you spent $50,000 on advertising at X, right? That was the silver bullet to get verified, like back before they just gave verification to everyone. So you could have a verified account if you just literally put $50,000 into your advertising account. Didn't even spend it. You wouldn't even need to spend it. You just need to actually put it in there. So product ends the same way, right? LinkedIn is the same way. you have intent, if you have money and you have intent to spend that money, with these platforms, you will obviously have a huge bump. Also, like with agents nowadays, a lot of these companies that build AR very quickly, they're using agents ⁓ very well, right? So I think comparison is terrible, right? So a lot of these bootstrap startups and these smaller products, they're comparing themselves to people that have money and have agent orchestration that's crazy, right? So one thing that I've recently started doing with Launch Chair, like recently as of today, is I have agent orchestration set up for LinkedIn. ⁓ for finding me warm leads and connecting with people and just doing basic engagement because in all reality, I personally hate LinkedIn. I would love if I never had to open that app. I enjoy being on X. I do not enjoy being on Reddit or being on LinkedIn. So any way that I can personally offload that work to an agent is a win. ⁓ And yeah, I mean, we've already like seen a pretty good uplift in MRR with Launch Chair, automating LinkedIn. Though it is tricky because like you're using your personal account. You obviously like, I think my personal LinkedIn account is like over, it's probably like 20 years old. So if I, you know, got banned or got restricted in some way, that'd be terrible, right? Or if I got my account deleted, that'd be terrible. So it is tricky. have to like, you know, tread with caution when you're automating these, these, ⁓ channels but Yeah, so I mean, I think that is something that people should keep in mind. Like there's a lot of these like YC backed companies who, know, we have a million ARR in three months. Like you don't know the whole story. You don't know what resources they have. You don't know what connections they have, what assets they have. If you're truly bootstrapped, I mean, the best way to grow is just authentically and organically. And I know I said it like using agency. I'm not telling people to like just become a Claude Slop Cannon and just spam. everyone they can, right? Like you have to do this methodically and ⁓ you have to be somewhat authentic when doing this. But yeah, slow growth is always going to win if you're bootstrapped.

Niklas:Yeah, it's interesting. And if you look back, what are the biggest lessons that you've learned over bridging design and engineering teams over 15 years? I mean, it's been a long time that you've been in that industry, right? And how does it change with wipe coding? I think it's very different today, right?

Jacob Counsell:It goes through cycles. I mean, it's different all the time, right? So for a while there, I don't know if you remember, but there was a large call for ⁓ product designers to become what they call full stack designers in the sense that like a product designer would actually code, a product designer would actually like do front end work. This was probably like 2015. And you made a ton of money if you were a full stack. product designer and could actually like facilitate code on the front end and actually work very closely with engineers. And then, you know, we started getting further and further away from that to the point where, you know, I feel like a couple of years ago, ⁓ we had engineering teams like chastising designers saying like designers never touch code designer. I've been told designers never touch code and I. Don't want to sound arrogant, but I am a better front-end engineer than a lot of the engineers I've worked with in the past five to 10 years. And that's just because they don't really care about front-end. Who cares most about front-end and what the end user actually touches? It's generally always going to be the product team, right? So now with the Gentic coding, actually love it because now everyone that was saying like, designers shouldn't touch code, it's completely flipped, right? Like designers absolutely should touch code. And I think designers are gonna touch a lot more code ⁓ in the coming days. You know what I mean? Because another thing like that that's really funny is like you have these engineers that are on X just screaming about, you know, slop ⁓ coming from. Fibcoding, right? But anyone that's worked in the industry knows that, you know, engineers have a very rich history of, of, know, shipping spaghetti code and broken functionality to, to prod, right? I mean, that happens quite often. So like, is, is there going to be any more or any less slop? Like, I think there still needs to be like checks and balances, but I think there's going to be a point where, you know, designers are doing and managing a lot of the front end. which I'm excited about.

Niklas:Yeah, think you can, as always, can differentiate, right? So I also believe that there are a lot of terrible designers and I would also question a number of product decisions, not only in like smaller companies, also in large companies. Like when I, I think the last time, for example, they changed the Google OAuth thing assigned on workflow, I felt the new version is terrible. Like these, there's this like classical way. these days where you enter your email first, then you go to a second screen and enter the password. think that's a terrible design choice. Like, put two fields below each other, it makes no sense to have a two-step process, at least in my opinion. So it's an extra click for the user, very little value added. I think so that, I think that it's really, and on the other hand, I've always, and also when I worked with startups in the past, really advocated for the developers to just take over design and product work. Like the people who also do the tech, I believe they can get into that. They should ideally talk to the customer and understand it anyway. I don't really think it should be decoupled. also what I think should happen, at least in my personal opinion, yes, if you're a technical person and you are a product manager,

Jacob Counsell:⁓ yeah.

Niklas:You can probably just do more and become more full stack, but otherwise I think technical people should move up the chain. should take a look at design. They should also take a look at product management and ideally understand the bigger picture because what I honestly believe with what is currently going on, I think people will become more like what you are already doing. So we will not have this this role where you have a Jira ticket and you do the implementation. That will become.

Jacob Counsell:Yeah.

Niklas:a lot less common than we have it today. We will just need fewer people on these roads. I honestly believe that.

Jacob Counsell:I mean, I honestly believe that everyone needs to be more collaborative. There needs to be less walls. There needs to be less like silos, right? ⁓ I think engineering, you know, part of the reason like there are so many production bugs and so many apps, so many large SaaS apps have like production bugs that I've seen for years. I mean, a good example that is like Figma, right? There's, there's bugs in there that drive me absolutely crazy. I don't use Figma anymore by the way, but there's bugs in there that have been there for like two years. And I'm just like, these are obvious bugs that people deal with on a daily basis. And the reason that kind of stuff happens is because the engineers, they're not close enough to the product. They're not close enough to the user. They're not using the products that they're working on. And same thing on the other end. I hate to say this because I've worked with a lot of really good QA people, but the role of QA in general, that has always needed to be engineers and product designers. Like who best to QA a product but the person that built it and designed it, right? So I think like all of these, these departments need to become smaller and need to become closer and feedback loops need to become a lot smaller. So I totally agree with you like a hundred percent. Like I think that if you have a PM, a product designer and an engineer and they're all kind of like bleeding over each other a little bit, like that's not necessarily a bad thing. And I think that big tech has kind of told us that that is a no no. And so when I was at a company, a FinTech company called Gabby.com, We shipped product so damn quickly and it was purely because we had one PM, a COO, like two engineers and myself. I was coding, the engineers were also like giving a lot of feedback and a lot of input on design. We were all actually using the product and we had no QA people. So nothing was removed, right? We all like touched the product daily. all were in there watching like hot jar sessions. We were all watching like users actually use the product, right? And I think that's where things need to be. Like, I'm not kidding you, ⁓ a team of five can ship, you know, what a team of like 40 were shipping a couple of years ago. And now that was before agentic, right? Like, so now with agentic, if everyone on the team is using agentic, ⁓ know, software to help them. Like, yeah, a team of three can do, you know, what a team of 50 was doing, you know, three years ago. Like, I fully believe that.

Niklas:Yeah, 100%. I think it depends a bit also on your industry, obviously, where you're in, what the expectations of customers are. If you are developing a banking problem, it's just not acceptable that things break. So you would probably always have a slower, more bloated workflow, which I think is fine. That's just the way it is. For other tools, especially when front-end failures that just get solved.

Jacob Counsell:Yeah.

Niklas:relatively fast are acceptable. ⁓ I think you're in a very different story. Just you can work with one or two people on products. And I think we've seen that with X lately. You talked about it as well. And as I understood it, there was one person developing the XChat app alone. It's more or less one engineer that built it. And that is, I think, very... different from what we have seen, it would have seen two years ago, but it's now feasible and I personally like the app. And it's also interesting, I've written with Nikita Beer, for example, a few times and he listens to feedback. Like if I tell him, really don't like something, he will at least listen to it. It doesn't mean he will implement it, but he's reachable on these things. that is, think... It's really important and that's probably also the difference to Figma where these things get lost somewhere in the organization because these bugs get flagged. They then somehow don't get solved. think. What's your take? Why does it happen?

Jacob Counsell:I mean, again, I think it's just the silofication, not a word, obviously, but the silofication of roles, right? And I mean, also at some of these larger companies, I'm going to circle back to like, you know, hiring like weirdos, like hiring passionate people. If you hire someone and their their main goal is just to collect a paycheck or be with a company long enough for them to go IPO, I feel like in reality, they don't They're not passionate about what they're working on. Do you know what I mean? You need people that are genuinely passionate about what they're working on, because those are the people that are going to find edge cases and find bugs, and they're going to be in there using what they've designed and what they've built and what they've coded. Those are the people that we need to see more of. And I think Figma too. I've hated Figma since I switched from Sketch. And that's purely because when I was using Sketch, that was like the era of the full stack designer and designers were touching code more and getting closer to front end. ⁓ But, know, Figma, I feel like we went backwards, like every year just backwards further and further to, you know, the point right before Agentic where we got to this point where everyone was just using a design system as a crutch. Like they were just using, you know, material or fluid or Shad Cien or Tailwind. and they weren't actually doing any real work. And then they were over indexing on user research, which is a whole nother thing that I think is actually kind of crazy that tech has done. Assuming that your target ICP knows exactly what they want and what they need is crazy. And throwing all intuition out the window is kind of crazy as well. I've always been an advocate of setting up a baseline. You have a baseline product and then you do like A-B testing on that baseline. and you iterate on that baseline until you get something that users actually want to use. You see what works, right? I think that I see a lot of product teams become inert in the sense that they will over-index on early user research. And before they actually even get something in the hands of a user, they've done months of work. And they don't even know. It's all an assumption. Do you know what I mean? It doesn't matter. You have quantitative and. I don't know, I feel like a lot of it is user bias and confirmation bias. And ⁓ with the Gentic, think we're gonna, you know, in the future, see a world where we rapidly prototype things and get them in front of users immediately. And then that's gonna kind of show us the way. And then you iterate, like an iterative process I feel is always gonna win. I don't know.

Niklas:Yeah, you need to talk to your customer. I think the basis is always if the customer doesn't know what the customer wants yet, you need to show them what you have and then you get some feedback. But at the end of the day, somebody buys your product and you need to talk to that person. Nobody else matters. Investor doesn't matter. Your coworkers don't matter. The engineer doesn't matter. What matters is whether the person that

Jacob Counsell:⁓ yeah.

Niklas:pays the bills, buys the product at the end of the day because they think the product is great. And like everything else is nice to have. Maybe people have good ideas and you need to talk or show them to the customers. But at the end of the day, it's do your users or customers use what you build and can you focus your product? think that's also don't get lost in a world of things. Do one thing really well in the beginning. And maybe that's also good. transition to your products. When you started your latest projects, what made you think I have to solve it? What were the large pain points that you thought I have to tackle them?

Jacob Counsell:Yes, I mean, with launch share, one thing that I was really focused on was just outcome, like user outcome. ⁓ I was seeing just an overwhelming amount of like dot lovable sites that barely worked, had, you know, tons of bugs. And then you learned that the person who built, you know, the, the product was, you know, spending four months on it. Right. So. I was thinking like, not only did you spend four months on something that feels broken and kind of feels like it was made in like bubble IO, if you remember what bubble was, I think bubble is still around, but ⁓ it's also not validated, right? You've done no research, you've done no product research, you've done nothing, right? You've just, you had a hunch and then you ended up with a fire tweet generator or another Reddit scraper. and it feels broken and then you're really bummed out that you spent four months trying to build this product with Lovable. And no offense, I think Lovable is great for prototyping and I like the product. ⁓ So also on the back of that, realized that, you know, everyday people are not prompt engineers. Engineers aren't even good at writing prompts. Like I'm absolutely shocked when I see some people's workflows, ⁓ designer, PM, engineers, like they're just writing very... unstructured prompts, That have, you know, no, that have bad context or bad scope or they're forcing the LLM to like read the entire code base or read completely unrelated ⁓ parts of their code base ⁓ or retrying a ton of times. And this is just obviously burning tokens like crazy. So I was thinking like, what if there were a kind of guided workflow that goes phase by phase and kind of leads you through like proper product research and, you know, a proper product definition and creates a scope and creates a PRD. And then we automatically generate feature by feature prompts based off of that spec and PRD. And each one of these prompts has, you know, ⁓ strict agent contracts, feature scope. ⁓ you know, guard rails and, ⁓ you know, ⁓ yeah, I was thinking like, if that existed, I think that'd be awesome for, you know, even more advanced builders. Cause you could get an MVP out very quickly. And then from that point on, you're free to like add functionality, add features, ⁓ vibe code, if you want, make it look however you want. Right. But you already, you have this, this solid bedrock, right? You have a fully functioning app. ⁓ and then. As I was doing this, was thinking, like initially I was like, what if it was just, you know, a whatever MVP, I just spit out an MVP for you. But then I was noticing as I was like. figuring out my splicing algorithm, this algorithm that splices your features from your PRD and creates these prompts for you within our prompting engine, I realized that we could actually build very complex apps that you otherwise couldn't build with lovable. So for instance, you could build OCR functionality into your app. There's a bunch of stuff for state machines. You could also build NLP logic into your apps. And so just thinking like, what would I want to use like personally as well, right? Like if I wanted to say, say I wanted to like rapidly like say I want to do essentially have three products in the market at all times and like kill whatever one doesn't work and then spin up another one and just keep like testing the market to see if something like is sticky. Like what tool would I want to use? I wouldn't want to use, you know, lovable or base 44. Cause I feel like, you know, if something doesn't work, if something isn't that complex or the feature set is

Niklas:you

Jacob Counsell:coherent or I have to do a ton of like research to make sure it's validated or make sure it doesn't have market competition or make sure you know it doesn't have a ton of like competitors with similar feature sets like that's going to eat up a ton of time right so that's why I was thinking launch chair would be a nice to have and actually our my other two products ⁓ one of which is my wife my wife's build hop and prompt joy those are both built using launch chair so we dog fooded ⁓ launch chair to get to pretty solid baselines with both those products and now they're both out there and ⁓ we're kind of just like refining and tweaking functionality but we originally built this as like a case study and BuildHop's kind of blowing up like we're getting a pretty decent amount of attention with that after two weeks of having that live and unfortunately Prompt Joy like was built purely for a case study, it has probably a hundred users but haven't really put much time into growing that one yet. Yeah.

Niklas:And how far along are the other ones? Like, how many users do you have?

Jacob Counsell:So I think Buildhop has about 60, it's been live for two weeks, has about 60 live launches, has about 130 users. We actually just released a pretty cool feedback feature for founders that have launched on it. And we also just added a free directory of free launch sites. There's like 168 in there and it has a you know, launch impact algorithm that tells you like, ⁓ you know, if it's good site to put your product on and it's not just based off of like DR, because as you probably know, there's plenty of like dead launch sites that have a high DR and have like 14,000 junk backlinks and you're gonna put your product on there and probably never see, ⁓ you know, their URL pop up on your analytics. ⁓ So yeah, that one's doing pretty well. Promptory has like a hundred. users, maybe a little less, ⁓ but no one's really creating prompts. What's interesting about that is the idea there was, ⁓ again, I want to help people become better prompt writers. So it has this rubric algorithm that helps you write better prompts and actually grades your prompts based off of a bunch of criteria. And ⁓ as I scale that, I'm also going to add MD and skill files. So you can write MD and skill files and rate them and grade them. ⁓ have it automatically improve them. It also gives you bunch of insights on what exactly you should change about your prompt, your MD file, or your skill file, so you know in the future how to write these files and these prompts better. And yeah.

Niklas:I'm not sure if people are really looking for that, right? I don't know, you will tell me, but my feeling is if I look at how I did this myself, it was just learning by doing. And then I would look at Claude, for example, I use Claude code a lot, so I have a max plan. So I also use the chat ⁓ functionalities of it. And I would, this is just like fine tuning over time, at least for me, I've never looked at some external advice on it, but it is just. internal AB test, you see what works and the next time you will fine tune it a bit more. so yeah, that is, the other one is quite, quite interesting. And also, yeah, I've never looked, I think lovable and also replica and bold. are quite far away from how I build. I'm technical, like, so I use cloth code. I know what the stack is that I'm using. know which questions to ask, but I want to look at. So I'm not, I'm not their customer.

Jacob Counsell:I'm gonna throw it.

Niklas:I think the love of a customer is somebody who has never built a website or product and wants to do it. How do you like it? Did you try it?

Jacob Counsell:Yeah. I've used like lovable bolts and base 44 and replet ⁓ in the past just for like prototyping just to kind of test them out. And then also we did play with them quite a bit. We did play with them quite a bit ⁓ in doing research for launch chair. And again, the prompter thing is mostly just a case study for launch chair and what we can build with launch chair. Yeah, I do. do think one thing to touch on with Prompt Joy, like I agree with you. Like, I don't think a lot of people that have been writing a lot of prompts like need it. But if you were to have, if you were to have Claude or ChatGPT write a prompt for you and ⁓ put it into our algorithm, it's probably going to score around like a 61, 65, you know, ⁓ that's what we're noticing. And then if you, the output and the token usage from a prompt that has been refined in Prompt Joy. is actually much better. Like there's way less token usage and there's a better output. ⁓ So I think there is maybe a place for it. We'll see. I mean, that's again, just a case study. But yeah, and Launch Share ⁓ on the technical end, like I think this is for like builders that are trying to get, again, trying to get a baseline out as quick as possible. Like builders that maybe build like multiple products ⁓ or don't want to do all of the like, you know, structural work. They just want to have, you know, They have a feature set in mind or they have an idea in mind and they want to that feature set out as quick as possible. And then they're, you know, free to use their technical skillset to refine it ⁓ all without writing prompts and having like a structured, you know, phase by phase flow and like a Kanban board of features. Another thing that's really interesting about Launch Chair actually from a technical perspective is so the prompt engine will generate a prompt for you for each feature, right? When you run the prompt, Like obviously it's, it's, ⁓ you know, these LLMs hallucinate quite often. Sometimes they don't fully finish a feature. sometimes they, you know, build features in a weird way or a good example of that is like load more. ⁓ so like lazy loading and load load more, a lot of people don't, a lot of vibe coders don't realize it's not actually building it for you. It's not actually like fetching that data. Oftentimes like say you have a list of a hundred items. it will load all 100 items on initial page load. And then it'll just arbitrarily hide them on the front end. And then when you hit that load more button, it just, you know, kind of in a fake way loads in those results, right? ⁓ So with launch chair, not only do we kind of force, ⁓ your LM to build, you know, fully functioning features the right way, but we have automatic acceptance criteria for each feature. And we, if, for whatever reason, what, your LLM built doesn't pass that acceptance criteria, ⁓ we automatically generate a remediation prompt. And when you use that remediation prompt, goes through and forces the LLM to like either fix what it, know, if it hallucinated and did something weird, it forces it to fix it. ⁓ Or if it didn't fully finish the feature, it forces it to fully finish that feature and build it the right way. So for example, you know, things like lazy load, like it will force it to actually. only fetch a certain number of items and then actually fetch those items instead of just like doing some front end animation for you.

Niklas:That's quite interesting. And maybe as a last question, if you look ahead for two or three years, how will the role further change of product designers with AI continuing to get better integrated? I think that's already quite good. think what we are lot of seeing now is that the software layer above it gets better and better. What will be the big impact over two to three years?

Jacob Counsell:Yeah, I mean, my hope is that designers kind of step into the role a little bit more ⁓ in two ways. I feel that there's no reason why a product designer, ⁓ what they're actually working on isn't real and tangible and immediately usable ⁓ by an engineer or immediately ready for production even, right? If you're working on a small feature or a small micro interaction. ⁓ and you've actually taken the time as a designer to be very thoughtful about what that micro interaction does and how it should perform for the end user, I don't see why there isn't any reason that that isn't production ready in the future and ready to deploy. And then that also alleviates QA, right? You're doing the QA as you design it, which I think is interesting. So not only you're working on this feature, you're working on all these micro interactions for this feature, while I'm designing it, I'm essentially already doing QA and it's gonna be production ready, right? I think that's ⁓ awesome. I also think that ⁓ the way that we're prompting is probably gonna change quite a bit. Prompts are always going to exist because we've kind of gone down this path of talking to these LLMs. But I do think that a lot of like generative... ⁓ assets are going to obviously not be a thing and become better. Right? Like the whole concept of like ⁓ creating a spec and a PRD, the fact that these are hard assets with a PM is crazy to me. I think these should be like living assets that like grow and change and evolve as engineers and designers work. Right. I also think PMs are probably going to be a lot more involved in the design and engineering process as they should be. ⁓ But yeah, mean, again, double-edged sword, right? I think there's a lot of companies that are trying to push PMs into both the design and the engineering role because of the Gentic. But what's dangerous about that is we've already, we've already seen the internet become insanely boring with like, know, ⁓ pushing like over index over indexing on user research and using design systems as a crutch. now what happens if we take, you know, PMs who don't have taste, who don't have design sensibilities, who really don't know like pattern work or UX patterns or like what a micro interaction should, should do or how it should feel. What happens when they're the ones actually pushing product, we might, you the internet might get even worse. ⁓ So I do, I do, I'm a huge advocate of, of design. think design should always have a seat at the table. I think engineers and designers need to work closer together and there needs to be less of a gap there and they need to be like in the same room at all times kind of thing. You know, like this whole like separate department thing has not been working for the past 10 years. And yeah. So I think it's very exciting. I think the future is, it's scary for a lot of people, but I mean, if you're technical and you have like design sensibilities and taste, I think that you're gonna have a very bright future.

Niklas:Really lovely take to end it. Jake, so great to have you and to you my lovely listeners. See you next time.