AI Field Guide: How AI is Reshaping the Roles of Design and Engineering

AI is reshaping the roles of design and engineering, emphasizing collaboration and how models can accelerate workflows without sacrificing quality. This week’s episode explores how designers like David Shackelford, Associate Director of Product Design for Method, use tools like Perplexity, UX Pilot, and Figma Make for rapid exploration, while Paul Rowe, Principal Software Engineer at Method, discusses the engineering reality check with tools like Claude Code and Google’s Anti-Gravity IDE. The key takeaway is a practical playbook for speed with guardrails, affirming that human judgment, taste, and accountability remain the multiplier.

The Methodites cover where AI currently shines—producing accurate results for smaller, well-defined tasks—and where it struggles, often leading to code bloat and confusion with vague prompts, especially within massive enterprise codebases. Despite the excitement around "vibe coding," they stress that the core development workflow remains "build, validate, iterate," with human review being more critical than ever. Paul and David conclude that while AI is an efficiency tool that can blur traditional departmental lines and shift where time is spent, strategic roadmapping, quality assurance (QA), and deep, expert-level skill sets in both design and engineering are still indispensable.

To find more episodes, visit method.com/insights/podcasts/

Episode Resources: 

Method.com

David Shackleford on Linked-In: /in/davidzshackelford/

Paul Rowe on Linked-In: /in/paulcullenrowe/ 

Transcript

Welcome And AI Focus

Josh Lucas 0:00

You are listening to Method's Build What's Next. Digital product perspectives. Presented by Global Logic. At Method, we aim to bridge the gap between technology and humanity for a more seamless digital future. Join us as we uncover insights, best practices, and cutting-edge technologies with top industry leaders that can help you and your organization craft better digital products and experiences.

David Shackelford 0:25

Hey, welcome back to Build What's Next. I am David Shagleford. I'm a associate director of product design, which means I build uh build nice experiences and move some pixels around. I've been in Method for about five years, and I'm here with Paul Rowe, who's a uh principal software engineer, and we're gonna be talking about AI and specifically the impact it's had on our workflow and kind of also do like a QA. I kind of want to pick his brain a little bit on things that I want to know about AI, specifically in the engineering world. Hey, Paul, can you give these guys an introduction about more about your role and kind of what you do here at Method?

Paul Rowe 1:03

Uh I am one of our principal software engineers here at Method. I have been here for about seven years now, and most of that time has been spent building front ends for our enterprise financial clients. But over the past year, I have been given the opportunity to help Method carve out our opinions and workflows and practices around AI tooling and AI-assisted coding and AI collaboration with design. So it's been a very fun year of experimentation, and I have had a great time learning how these things work. But I'm very curious to know how it's been impacting the design world. So I'll be asking you a lot of questions too, David.

Specialist To Generalist Shift

David Shackelford 1:43

All right, thanks, Paul. Just to give you a heads up of what we're talking about today, uh, a couple topics I'm going to throw your way. We're going to talk about the change from specialist to generalist, uh, some kind of tools and experimentation that we've been doing, uh, as long as like real-world examples, and then might get into like the future and outlook of where things go, as well as I uh selfishly, I want to ask some QA's. I don't often get to just like interview an engineer and just ask him whatever I want. So we're also going to be doing that. First thing I want to get into is the shift from specialist to generalist. Um, can you talk to me about kind of how you view yourself? Do you see yourself as a generalist or do you see yourself as a as a specialist and how has AI kind of shifted that? And I'm asking this because I I feel like AI has opened a lot of doors and created, kind of shifted everyone into the generalist like label.

Paul Rowe 2:41

Yeah, I think so too. Uh it's what it's enabled us to do is add some expertise where we historically had a lot of gaps, especially in like the enterprise world. And I'll be curious to kind of track how enterprise teams start to adjust to this, because we're really starting to see the lines blur between the traditional lanes of how engineering and design organizations are built at scale. So, for example, if you've got a hundred-person engineering team, you probably have a bunch of front-end engineers that only do front-end engineering, a bunch of back-end engineers that only do back-end engineering, some database engineers who protect the data, um, and a whole bunch of other like very specific lanes where that is the skill set you need, and that is the like your particular tasks for your foreseeable future at that company. We've seen AI start to help us fill those gaps, right? So if I'm building a smaller application, I can work across the back end, the front end, do a lot of DevOps work, and I can even collaborate with designers who are passing me Figma designs for a UI, and I can kind of drop those in and start generating code right off the bat. How good that code is maybe questionable, but it is a it is an enabler. It's something that can start our foundation of work with a lot more ease and a lot more speed. So I am that's how it's worked in engineering, but I know that in design as well, there's there's lanes of that, right? There's researchers, there's designers. Honestly, you should tell me what those lanes are, because you probably know better than I do.

AI In Enterprise: Limits And Wins

David Shackelford 4:19

Yeah, for sure. Like, so a little bit of background on me. I I've always pretty much in my professional life considered myself a generalist. I like went into school wanting to learn everything on design, and then after school, got into the startup world. And in the startup world, you're doing everything. We're moving fast, we're breaking things. Um, so I dipped my toes in every aspect of design. I've done illustrating, I've done product design, of course. That's kind of my bread and butter. But I've done like 3D modeling, I've done front-end development, because in startup world we didn't have a front-end developer, so I was the front-end developer. Uh so I have a little bit of code chops. That's kind of that kind of like that background is really like not to like brag and be like, wow, I'm really good at this, like kind of AI thing. It's really like benefited me into like dipping my toes into everything. And and what what AI has really helped uh do is open up research uh and engineering. I think like that's where design is sandwiched in, right? Uh so we get to like with AI, you have like aspects of it where you can use like LLMs to create even synthetic uh research and uh use it to summarize research that we've we have. Uh we can make have it create PRDs on the engineering side. You can get into vibe coding, you can get into just building things that are like straight to code and you kind of learn more that way. Talking about all of this kind of gets me into the next topic of like tools and experimentation. I I think I'm really interested to know what like kind of your like dream stack is right now uh for AI, like as far as how how are you working with AI and how are you implementing implementing it into your workflow and what tools are you using?

Paul Rowe 6:11

So I think the way that you use AI really depends on your environment, right? So AI, we've seen it prove itself as very effective in greenfield environments where you don't have anything in your way. You're starting with a clean slate and you can kind of make decisions on the fly. You don't have to take in a lot of historical context or code styles or existing ways of working. We've seen it work really well there. In more brown fields, more like trotted trotted ground, right? Where you've got existing software and you need and you want to try using AI in that in that code base. We've seen it struggle a little bit more. And I think that part of that is in bigger software, you have a lot of historical decisions that are made that AI doesn't have the context to. It doesn't know why your business works this way, it just knows what you told it. So it doesn't have those historical decisions. There's no log of why certain things or certain workarounds are built the way they are. We are starting to figure out how to use AI in those situations. And usually that means slim down the task as much as possible, right? So the bigger task you ask AI to do, the less likely it is to be accurate, like do it, do it the right way or do it the way you wanted it to. So that is kind of what happens in enterprise code. Anything that you ask it to do, it has to take in the context of this massive enterprise code base. And it kind of loses sight of where it's supposed to go. It might make a lot of changes that you weren't expecting. With any with any AI tool, the smaller the task you make, the more accurate it's gonna be. It's gonna be a lot easier for it to know what is correct and not correct. It'll be much easier for you to review and it becomes a lot smaller output. So it's easier for us to validate that it's doing the right thing. There's one more aspect in this where I think people are overestimating what AI is capable of. Today, I don't think AI really changes the way that we build software. I think it speeds up certain aspects, but at the end of the day, my workflow is the same. So I might have spent two days writing code to build a feature before. Now I might work with AI, and that coding part of my day might go from two days to two to three hours, right? I'm still, I know what I need to build. I know how I want to build it. I have to tell the AI how to do that. I have to go review that it did the right thing. I have to fix anything that it didn't do correctly, which happens every time. Sometimes I have to throw away everything that it did. And the workflow hasn't changed. It's build, validate, iterate. And so we might be able to take out that two days of coding, but now we're generating a lot more code. So we have a lot more review and we have a lot more of that part of the work to do. So, and I think there's a number somewhere of like any developer, maybe 20% of their day is actually spent coding. So if you're bringing that 20% down to maybe 5%, you're still you're still filling in the gaps with things like meetings and strategy discussion and thinking through ideas, working with your designers. It it doesn't change the day-to-day, it just changes where the hours get spent.

David Shackelford 9:31

Can you tell me more about like what tools are you using? That was the first question.

Tool Stack Showdown And Setups

Paul Rowe 9:35

Yeah. So the tools that I have been playing with a lot lately are clawed code and anti-gravity. Anti-gravity is the new IDE that Google just released, which operates on its Gemini Pro uh 3 model. It has been both of those are very comparable. They are good at building complex things. That said, you don't want to build ask them to build big things, ask them to build small things. I like clawed code and anti-gravity. I'm kind of letting them duke it out right now. I like tools like Figma and Figma Make. I can design something, and Figma will just whip up an actual interactive prototype that's built with code. And I tend to use like other smaller tools, LLMs that I plug into my systems. I like testing things with a model called Cohere. I like doing voice transcription with Super Whisper and other Whisper models. I think it really depends on what we're doing and using the right tool for the job. There's just so many today.

Design Workflow Supercharged By AI

David Shackelford 10:34

Yeah, yeah, completely agree. Like when I reflect on my process and kind of the tools that I'm using, it's not consolidated. It's uh everything. So, like up front, when I start a project, we'll start with the research. Like it, like AI has opened up the door for me to get into research and really like understand how to write out like actionable documents. So, what I'll do, like, let's say I'm on a project and like sometimes on this pro on projects, we don't get the luxury of user interviews. I can go to Perplexity and source out public feedback or like public reviews, forums, anything that I'm focused on, on the subject I'm focused on, and I can get feedback on what customers and users are are experiencing. I'll take that and then I'll use an LLM, could be ChatGPT, could be Gemini, could anything really to create a PRD or a product product requirements document. I'll then take that PRD and then move it into Figma make or UX pilot. I'm using these PRDs to create a bunch of variations. I'm I'm using like at this state, I'm probably I'm in lo-fi and I'm using AI as an assistant. It's like having, we'll say, like a junior level researcher and then a junior level designer pumping out variations of what I want to explore. All of this has validation that needs to be done. Like you're you're reviewing this, you're reviewing all these outputs, you're making sure they make sense. Oftentimes they don't. So then from there, you're getting into like prototyping and you're getting into like vibe coding and and creating interactions. What I think what I think it's done for my process is it's opened up doors for a couple things. It's opened up like to create variants and really explore variants, getting those in front of clients quickly, like the whole move fast, break things aspect of my my working style, my background. I'm applying that upfront and early. So I'm getting a lot of like variations out there, a lot of iterations out there. I think it's opened up that ability and to do that quickly. I think it's also opened up the ability to focus more on brand with Mid-Journey. It has a bunch of like features where you can like create a mood board. If we need brand exploration, I'm not the biggest brand guy. We have people that are that are here that are great at it, but I am not. So being able to like get essentially a junior uh role to create like brand ideations and ideas and things that I can approve to put into a design is great. And then also you can really explore things that are not possible in current software. Like there's a done, there's a bunch of like like an example would be uh we built a dashboard and it had drag and drop features and like customizations and snap grid to drag and drop widgets around the dashboard when you customize it. Very hard to build in Figma, like but decently quick to build in like a lovable or a Figma make. So like building that out and like testing it and getting validation on it and being to the client, here's the interaction, here's what the user experience will look like is really valuable. And then also from the user testing perspective, those like vibe coded prototypes are way more intuitive than a Figma prototype. You can build those out relatively quickly, and and I'm using the word validate a lot, but you can validate with users pretty quickly in like an almost real-world real product environment. Uh so it like at that point, it's like all of these things are very valuable. So I've talked about a couple use cases, like the like the dashboard, the real real example. Do you have any like real examples that you're using these tools that have really like benefited you?

Paul Rowe 14:30

Yeah, we're working with this one client that is exploring implementing AI into their design to development workflow. And something that's really cool that's coming out of that is we now have tools that can take a design system and you describe, you can prompt for a UI to follow certain patterns and make sure it uses components from your design system. You can do the same thing on the developer side, where the AI will reference your component library. Say you have a Storybook component library that matches your design system, and you can hand your development tool, whether that's Claude Code or Anti-Gravity or GitHub Copilot, you can pass it your Figma file, tell it to reference your component library, and it will start spinning up that UI with exactly the components that you're using in Storybook. So it follows your design system, your style guides, your brand guidelines, and also follows the existing patterns that's existing in your code pit code base. So there's some really cool stuff that is starting to make that design to development handoff a lot smoother. And it makes it a lot faster for a developer to be able to build what a designer intended without breaking any of the rules of the style guide or design system. So it makes it very, very easy to architect UIs and build out UIs, especially when it comes to marketing, like, you know, more like website versus web app. It's very, very good at websites. Doesn't know what to do with the logic, though, right? So if if it's able to spin up a UI, it doesn't know what this button's supposed to do. So, and it doesn't know what kind of validations go into a form, for example. So there's still a lot of engineering that has to happen after those steps, but getting the initial UI spun up, it makes that whole process a whole lot faster and a whole lot more accurate.

David Shackelford 16:19

Yeah, I had a similar project where we were they were starting over with their front end completely. The final deliverable was essentially a coded, uh I've coded uh through lovable uh kind of interface. We can get into code quality later. That's one of my key ways. But it it gave them like a really refined, real, like real life prototype. I guess we're calling them prototypes, but they're live code. Um so yeah, they were able to pick that up and take those that styling and almost like copy and paste it into real live code. I think with this kind of like blurred line of to me, vibe coding is where things get interesting. I don't know what we're calling it anymore, just generative coding um is getting really interesting because that's where like design and development meet typically. And both roles are playing in that area. I think different viewpoints. I think with engineering uh and development, they're looking at it through uh codes, uh like uh like a co-pilot interface where they're looking at code, they can see the code, they can correct the code, where designers are looking at it through what does this experience look like? What does how does it look and feel? Does it does it solve the the user's problem? And it's often through a prompting interface, like a lovable or a VO. Um can you talk to me more about how you see the future specifically in this area moving forward? Like it do the do these just like merge into the same role, or how do you see that?

Design-To-Code And System Fidelity

Paul Rowe 18:04

Well, I think I don't think that they really f merge into the same role. And I think that there's a pretty clear reason why. And it's basically the reason why people get into design or get into development. It's because some people have a knack for making things look really good, and some people, like me, don't. So I I tend to focus on the the technical challenges and thinking at scale for systems to work together. That attention to that detail is not going to change how these two roles are defined. I think that the same exists in engineering too, because as much as I'd like to say I can build a back-end, a back-end of an application, I would really want a true back-end engineer with true back-end knowledge to go in and check out that I did I did everything right. I don't really trust myself in that. And I think that as much as I've been building back ends with AI assistance and I've been learning as much as I can, part of this, part of the beauty of hand coding things is this learning loop. As you're coding things and looking up documentation and learning about the practices for using your tools, you're learning about it and you're starting to catch patterns across the rest of the code base as you learn. I don't know if just reading generated code has the same amount of learning. And so I think the same exists for designers trying to code. I think that designers would still have a hard time reviewing the code that's being generated. For example, if you generate a React application and you accidentally introduce an infinite loop when a component keeps rendering, do you really know how to fix that? Unless you you're a designer with really good React chops. I would say the same thing for me as an engineer. As much as I can spin up Figma UIs, is auto layout like done correctly? Are my containers done correctly? I don't know. I know that these two kinds of texts look the same, but I'm not using the text component. I'm using just hard-coded styles and attributes. So I think that these two roles are still going to exist next to each other and work in harmony because those they still are a very expert level skill set that I don't think AI is going to cover in the next couple years at least.

David Shackelford 20:22

Yeah. Yeah, I agree. I I think there's limitations to just the knowledge base that the user is having at that.

Paul Rowe 20:31

I'm curious though, but on the design side, I kind of talked about like generating UIs and stuff. And I know that some of these new prompt design tools, prompt-based design tools, are kind of still just coming onto the market. But have what's your experience been like using those on the design side?

Vibe Coding And Production Reality

David Shackelford 20:48

So mixed reactions. Uh I would say I think it's all dependent on how well you know how to prompt. I think this is where like my PRDs come in handy. If you're building out these like intensive PRDs, the more you give it, uh like I think I think what you said about creating small things, you you can do that with like low effort prompting. If you're building out like an entire experience, you're gonna need like background like PRD. What's the what are the KPIs? What are what are we trying to solve here? What are the personas? So in that aspect, really good. I use it mostly for lo-fi stuff. So I'll build out interfaces and then I'll skin it as like lo-fi. Um, and then then later in like hi-fi exploration, don't really trust it to maybe if I you mentioned a software that you give it a design system and it'll work with that. I don't currently trust it with the software or the tools that I use to stick to a design system and be pixel perfect and do all that stuff. I think maybe like for a POC, sure. Absolutely. I don't uh it's all proof of concept. But if I needed to be pixel perfect, ready for delivery, it matches the design system, it matches the design system's code base. I don't trust it right now. Uh maybe, like maybe after messing with the tool that you have, maybe I would.

Paul Rowe 22:20

You also mentioned uh like you use the PRD. One of the things that AI tools don't really have a good concept of is vision, right? Like where is the destination? Where is this going? And it sounds like you use PRDs to help it keep that vision of what the product's eventually going to be in its context. Is that is that accurate?

David Shackelford 22:40

Yeah, yeah, absolutely. Like, I don't want it to seem like like I'm only using AI. I'm just focusing on the aspects of my workflow that is using AI. I am still in charge of the decisions being made. And the PRDs are sometimes even way off. Like I'll be in a meeting, I'll have it summarize the meeting, and it'll be way off of the direction that we were talking about. So it's you're still responsible for creating the solution. And there's very much a human aspect to that. Okay. Let me ask my big question. With what is your opinion on uh generated code and being how far out is it, if at all, to being production ready? Like working in a lovable or copilot and then being able to ship that code.

Paul Rowe 23:32

So pure vibe coding. Uh I believe that it depends on how good you are at vibe coding. So, for example, I wanted to push Claude code to its limits, and I was building a Slack bot that we use now today in method. So it has gone to quote unquote production. It's an internal tool, but it's being used by users. And I wanted to see how much of it I could vibe code. And one of the things that I did, I built a PRD like you do. And then I also had it create a roadmap of how to incrementally build this product. So I said, based on this PRD, let's create a roadmap of incremental updates and changes and additions to eventually build out this full product. And it's a big old to-do list and it lives in the code base. And anytime I want to when I'm ready to build the next feature, I say, all right, let's do the first item in section 3.6 of the roadmap. So it reads the whole roadmap every time, and then it goes after that one task. So it keeps the vision of what this product is supposed to do in its head, and then it goes and does this small part of that. Smaller I can make those tasks, the better the vibe coded output is. So I can and did like build a completely vibe coded app. I did have to go in and change a couple of lines of code here and there when it, you know, just doesn't didn't have the context of certain things, like API keys or just little things where it created duplicate code. But for the most part, it did it. Like it created a production app that is in use today. And I still vibe code any new feature requests. So I think it's there when it comes to building smaller tools, internal tools, it is great at. I'm still weary on whether I'd recommend it to start vibe coding enterprise software. It's just too big. Like that, those code bases are just too big. And so it starts to lose its accuracy because of that. But it is, I think that we're not far off from seeing those be a lot more accurate. The speed at which these things are like improving is astronomical. It's insane.

Prompting, PRDs, And Vision

David Shackelford 25:42

Yeah. Yeah, for sure. Yeah. And I think at that point, that's where like the lines really get blurred between that design and engineer. Like I I've had the same experience when I was when I'm by coding. And then I I want it to be production ready. I'm coming from screens, user flows that I've built out already, um, and they're high fidelity. I found in my experience I want to know, or I need to know exactly what I want to build out. And I need to know exactly the the experience that I want to build out in this vibe coder to prevent code bloat. Because I think if you're starting from scratch and you're ideating and you're just like throwing around ideas, you're gonna have a mess of code.

Paul Rowe 26:24

I agree with that.

David Shackelford 26:25

Just wanted to confirm that.

Paul Rowe 26:26

And I think it's it's funny too, because we were talking about these tools that uh can turn designs into code, just drop it in and it and it spins it up, right? Um that I think you've heard anybody who's like experimented with these tools has seen the quality of that output, right? These are like, these are they tend to be not optimal code. They tend to be referencing the wrong components or hand building an element when you had a component for it already. I think that we still have quite a bit of a way to go before that quality really improves. I actually have some questions for you as well, because I, coming as a former designer, now like full-time engineer, I was back in the sketch days when it was still kind of a glorified version of Microsoft Paint with some bells and whistles attached to it. I have, I feel like I have lost pace with Figma, as in it has gotten so good and I just haven't kept up. Have you found that using AI has allowed you to do more advanced things in Figma, or is it kind of in the way, or does it do basic things? How does AI perform with with these new features and tools that Figma puts out?

David Shackelford 27:39

I think Figma is still the home base of designers. And I like to Figma's credit, Figma make, and they're just rolling out like an inline like prompting AI feature where you can update like screens and just prompt it to up make updates or make changes. So I it's like the design world's still very much locked into Figma. I think everything else is kind of branching out, trying to bring things back to Figma, except for maybe the deliverable, like the high fidelity user testing deliverable where you need to vibe code something. That's definitely like that's taking things from Figma and into that software.

Paul Rowe 28:16

Has there been anything in the AI landscape of Figma that has really impressed you?

David Shackelford 28:21

Figma make was not as impressive when it first came out, but I will say recently we've been using it a lot. I wouldn't, I still don't, I don't think I love the code that it puts out, but I'm not using it for that. So I'm good with that. Um and I think if they like with this new feature of like inline prompting on your designs, if they can figure out to figure out how to make that like work within your design system and all the variables that you have built, I think that can be very powerful. Like an example would be like if you want to take a screen and then just make it into dark mode, just prompt on that screen, convert the screen into dark mode, it'll do it. If you want to take a screen, make it mobile responsive, just prompt it, say it, and it'll do it. I think if like that's like brand new, that's in beta that we have access to, and I still need to play around with it a lot, a lot more. But I think if that becomes really effective, that's gonna be a huge like like time saver.

Paul Rowe 29:22

Cool. Have there been any tools outside of Figma that you've been impressed with?

Figma’s AI And Lo‑Fi To Hi‑Fi

David Shackelford 29:28

UX Pilot has been good. I but I only use that for um for like rapid, like uh like multiples, like different solutions that I want out quickly. And again, I only use it for lo-fi right now. Maybe if I want to explore brand stuff, I'll do that and it'll pump out a bunch of variations. But again, I'm just using it for lo-fi. The I really only use it for lo-fi because the transfer from the UX pilot software into Figma, kind of like that I was saying everything comes back into Figma until the end, is that that transfer is not good. Like there's there's there's uh the file and those layers are a mess. So don't do that. It's good for creating the screens, getting them in front of them, and then rebuilding them with your own process and library. Don't build build from those screens.

Paul Rowe 30:22

That's cool. What do you think the the future of design with AI is starting to look like? What do the next couple years bring in your opinion? Or what would be really cool for it to bring, in your opinion?

David Shackelford 30:34

What I would want is more consolidation. I think there like all these AI companies are like there's so many of them and they all do like really niche things. I just want one space to bring it all together. And I'll like hear about I'll hear about a new one that one of our designers is using and think it's really cool, but I'll never get back to it just because like there's like there's a new one that'll pop up in like next month. So it's really hard to like stay up on all of them. I just want something consolidated. And I think that'll happen eventually. It's just very new uh in software. As far as the future of AI uh in product design, I think it's I think it becomes more, I don't know.

Paul Rowe 31:20

That's cool. I definitely agree with you. Yeah, I definitely agree with you about the about the consolidation piece. I said in the beginning, I've spent the past year just learning as many of these tools and using them and putting them to their tests as much as possible. And I still feel like there's a million very commonly used ones that I haven't touched yet. And people ask me opinions, and I'm like, I don't know. These are the ones that I use. I think it's good to kind of like categorize these things when the market is so broad and so uh fragmented. I think it's good to categorize these things into like, into like code assistants or code generators or strategic thinkers or design uh design generators, rather than thinking about one tool. It's what is the goal that you want out of it? What is the task that you want completed? And then figuring out which one's your favorite, favorite flavor of that problem solver.

David Shackelford 32:13

Yeah. Yeah. I like the reason I say I don't know is because there's so many what-ifs, like like because not to I don't know. It seems it could lean very heavily within like if the like the market leaned very heavily into the AI or into uh research and design more, and it got really good at vibe coding. I could see engineering becoming secondary to the AI software. Right. Not to like not to put you down.

Paul Rowe 32:45

But I mean I do think I do think that there's an element of that, right? I think that there are certain tasks that it can absolutely eliminate and like the need for a fully expert front-end software and like anywhere in the stack. It could eliminate the need for an engineer to actually go into the code and interact with the code, right? We're already starting to see that in tools like lovable uh and any of these other scaffolding applications. I think that it's for the complex problems, we will still need like software engineers. And you know, I think let's say 20 years ago, you needed you needed to hire a couple of at least one developer to build you a basic website with your name across the headline and a picture of you, right? Today you can do that with tools like Webflow or Squarespace. You could just drop one in, you get it for free, it's hosted for free. All of the, all of the operations behind just that one piece of HTML is all taken care of for free. I think we're gonna see a similar development with simple problems, right? We can abstract away a lot of the complexity that makes solving the simple problems easy. Doesn't really take away the complexity of the harder problems, though. For sure.

Fragmentation, Consolidation, And Strategy

David Shackelford 33:54

Yeah. There's code bases and backends that are massive that a vibe coder can not touch. Right. Yeah. And I I think I lean into that more like the if AI leaned more into an input of research, uh user flows and personas, and then into designs, if it leaned more into that, like that's my typical process. So I'm exposed to that. And the thing like they're my inputs that I'm using and code has almost become secondary to me to an aspect. But again, there's a lot of what-ifs with like production ready code and sure. Is this code good? I think I think if they solve, I don't know who they are, but if they solve that problem, that could be really interesting.

Paul Rowe 34:43

I also think, too, even if these tools get to the point where it can build software from the ground up, and again, I I think there's cases to be made to say that they can do that today, you still need the strategic thinking of how to build a product. The steps that it takes to go from 0.0 to 0.100. Um you you know, you can't just tell these things, I want a financial tracker app that digs into all of my bank accounts and spits out what I should be saving each month. Like that doesn't it's too big of a problem. And it might not come out the way that you want. And in order to fix that problem, it has to rebuild. And I don't think that I don't think that that changes, right? There's a lot of people who say, I have an app idea, and they'll tell you the idea, but that's the entire thought process. And it's not like how do we get there. So I think that strategic road mapping and iteration of uh incremental build is still a very, very deep skill set that isn't going anywhere.

David Shackelford 35:45

Exactly. Yeah, you definitely still need to apply best practices of digital product. Like I've seen people come with an idea, go on Lovable, and it is garbage.

Paul Rowe 35:56

One of my first experiments with Lovable was proving to a friend of mine who was asking about AI app developers and uh like Lovable, and I said, You should check this thing out. He's an old college buddy. So I had him build a beer pong tracking or beer pong tournament tracking application, and it did it. But my goodness, an AI has no idea what the culture is behind beer pong, right? So it looked like an enterprise medical billing application that just happened to track beer pong tournaments. So some of this is very like it it just shows that there's some of this is like intuitive human knowledge that just can't be replicated today.

David Shackelford 36:41

Yeah. I think like if anything, that's the through line is that these are tools and they are efficiency gainers, they are reflective, but human aspect is still 80%, 90% of of the work.

Paul Rowe 36:57

Absolutely. And validation to just being able to look deeply at what it's doing and correct it where it needs it. Because today you can't really just blindly trust it. It will make lots of lots of problems, especially in those first steps. If it makes a mistake in those first steps, you're building your entire foundation on top of that mistake. And that doesn't change if a human's writing it or an AI is writing it. It's just, are you glossing over that problem?

David Shackelford 37:25

And it is a very it's also a very bad look if you come to a client meeting with a just blindly trusted AI.

Human Judgment, QA, And Closing

Paul Rowe 37:32

Absolutely. You'll have a lot of angry clients, a lot of angry customers, users. It it becomes a big problem very quickly. Q like quality assurance, validation, evaluation, all of it has not changed. In fact, it's probably more important than ever. I would argue that QA teams should start growing because code is going to be coming in a whole lot faster now. And there's gonna be a lot more stuff to review, a lot more foundational elements that you have to check. And sure, there's automated testing. There's you can build tests with AI, but that doesn't change, that doesn't replace the human eye or the human experience. Does this process that the AI just generated, does it actually work well, or does the human hate it? So I think that that's never going to change. I think that, yeah, build up your QA teams.

David Shackelford 38:24

So if we were to summarize this episode, we talked about the idea of everyone come becoming a generalist, kind of the tools and the experimentations that we're doing here at Method. Um we brought up some real life examples and also talked about what the future could look like, as well as like selfishly asked some QAs uh to really pick each other's brain. But I think what we've we've really learned is that it's AI has brought us more together to be more collaborative and kind of broken down the walls of the departments to create more reflective and more efficient work and more efficient and higher quality products. Well, that's all my questions. That's all my selfish questions, uh, Paul. But but thanks for joining me. Thanks for letting me pick your brain. And thank you all for joining us.

Paul Rowe 39:15

Thank you, David. This has been a lot of fun. Appreciate you, buddy.

Josh Lucas 39:19

Thank you for joining us on Build What's Next Digital Product Perspectives. If you would like to know more about how Method can partner with you and your organization, you can find more information at method.com. Also, don't forget to follow us on social and be sure to check out our monthly tech talks. You can find those on our website, and finally, make sure to subscribe to the podcast so you don't miss out on any future episodes. We'll see you next time.