
The Story of Software · 2026-02-19 · 31 min
Key moments - from our scoring
Substance score
62 / 100
Five dimensions, 20 points each
Wesley Yu draws parallels between the electrification of industry and current AI adoption, arguing that companies face a choice between incremental enhancement of existing products versus complete reimagination. Using Metalab's work with venture-backed clients - including a dating app replacement for human matchmakers and a policy data platform - Yu emphasizes that trustworthy AI requires explicit permissions, visible context windows, and clear safeguards. He traces how mobile apps trained users on responsiveness and sensor access, Google Docs normalized real-time collaboration, and these expectations now layer onto AI product design. The critical insight is that productivity gains from AI will remain capped until organizations restructure workflows at a fundamental level, a process that took 30-40 years with electricity. Yu sees grassroots adoption beginning through developer tools like GitHub Copilot and Claude, where AI acts as a pair programmer accelerating individual workflows rather than replacing them, though he remains mixed on managing multiple agents simultaneously versus one-to-one pairing models.
Make permissions and access explicit by showing users what data the agent can see, what tools it can call, and what actions it can take. This visibility prevents both over-access (privacy risk) and poor performance (context rot), and is especially critical in regulated domains like dating apps or policy data platforms.
Because they're treating AI as an incremental upgrade to existing processes - like adding an electric motor to a steam-powered factory - rather than redesigning workflows from scratch. The electrification analogy shows this restructuring takes 30-40 years; we're only 2-3 years into AI adoption.
AI-enhanced products in existing sectors will capture the most aggregate value because AI will diffuse across established productive industries; AI-enabled products (those that cannot exist without AI) may hit bigger individually and create new categories, but the total market is smaller.
One-to-one pair programming is superior for complex, mission-critical work because managing multiple agents produces code faster than humans can review, creating alignment and conceptual integrity problems; multiple agents work better for minor bugs and routine chores.
While code-writing is enjoyable, the real pain in development is emotional - being stuck, uncertainty, context switching, and losing momentum. Good AI collaborators externalize thinking, test hypotheses, and restore momentum, making developers more deliberate and willing to refactor, which can improve satisfaction.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers solid mid-level substance with useful frameworks (e.g., layered expectations across tech waves, responsiveness as comprehension time, the electrification comparison) and concrete product design principles for AI. However, it relies heavily on broad abstractions and general observations without diving deep into measurable trade-offs, specific technical constraints, or quantified challenges. The discussion of hallucinations and trust is conceptually sound but lacks actionable specifics on how to actually solve these at scale.
every wave of tech doesn't replace the last one. It kind of Layers on top. And it changes how we think, what we think software is, our reflexes, our habits
the ceiling on return on investment by integrating AI into your company without rewiring some of your workflows is limited
The episode uses familiar frameworks (electrification analogy, responsiveness patterns, hallucination problems) that have become standard discourse in AI product circles. While Wesley articulates these ideas clearly, there's minimal contrarian thinking or first-principles reasoning. The electricity comparison, while effective, is now well-worn in the AI community. The insights on pair programming and multiple agents touch known trade-offs without fresh perspective.
AI has got a lot of similarities to the introduction of electricity. Back in the late 19 uh, hundreds or 1890
hallucinations seem like an inherent property of large language models
Wesley Yu is a legitimate practitioner - head of engineering at Metalab with 10+ years there, real client work spanning dating, policy research, and other domains. He has genuine operational experience building AI products. However, his seniority is primarily in design and product strategy rather than at the scale of leading major AI deployments or companies, which limits his caliber for an episode nominally about trustworthy AI and market strategy. He's solid for design perspectives but not a top-tier operator on the core subject.
head of engineering at metalab, an agency specializing in venture backed startup space
we're working with a dating application right now
The episode includes some concrete examples (Metalab clients in dating and policy, ChatGPT's search/drafting signals, GitHub Copilot, Adobe Firefly) but lacks deep specificity on metrics, timelines, or quantified outcomes. The anecdote about the junior engineer using ChatGPT instead of Figma plugins is illustrative but trivial. The electricity analogy cites the 1880s-1920s productivity gap but without citing sources. Few specific numbers, ROI figures, or failure cases are presented.
we're working with a dating application right now that tries to replace a human matchmaker
a company that manages a lot of policy data in the United States. They have indexes of millions of policy documents
The host (Ricky) asks reasonably structured questions and makes genuine attempts to follow up (e.g., on enterprise standards, on organizational appetite for reimagination, on hallucination solutions). However, the conversation lacks sharp pushback or productive disagreement. When Wesley makes claims - like the idea that pair programming is superior to multi-agent management - Ricky largely affirms rather than challenge. Follow-ups are often soft clarifications rather than probing for contradiction or deeper evidence.
Are you working with enterprises? Because obviously there's a huge amount for the enterprise with regard to uh, security and safety
is there an appetite for reimagination at the moment? Are you seeing any aspects of that
Computed from the transcript - who did the talking, and the words that came up most.
Wesley Yu is the Head of Engineering at MetaLab , a product agency working with venture-backed startups at the intersection of design and technology. His route into engineering was non-traditional, starting in media studies and radio production before moving into content marketing at a tech startup in the early 2010s. That shift put him close to the ambition and pace of the Silicon Valley startup world, and eventually led him into a coding bootcamp, learning Ruby on Rails and finding a “maker” mindset through software. He has since spent over a decade building web and mobile products and leading engineering teams. In this episode, we look at how each major software wave changes user expectations without fully replacing what came before. Wesley frames AI interfaces as arriving into a landscape shaped by mobile responsiveness, sensor permissions, and real time collaborative productivity tools.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign.
Speaker B: Welcome to the Story of Software podcast where we're joined by Wesley Yu, who's the head of engineering at metalab, an agency specializing in venture backed startup space where he focuses on the intersection of design and uh, technology. He offers a deep perspective on the evolution of product development, having seen the shift from the mobile era where gestures began to replace clicks through to Web3 movement. And in today's world of artificial artificial intelligence, Wesley will be sharing his expertise on the evolution of user interface and product strategy in the age of AI. Wesley, thank you so much for coming on and speaking to me today and really looking forward to it.
Speaker A: Yeah, thanks for having me, Ricky. I'm really excited to be here.
Speaker B: Excellent. So we always kick off with a bit of background about yourself. So would you be able to just talk us through quickly about your career history and really what brought you to where you are today?
Speaker A: Yeah, sure. I mean, I think a good place to start is that I didn't study software engineering in university. I actually went to school for media studies, which I like to describe as thinking about mass media and writing essays about movies and video games. Very fun thing to do. And it helped me get my start as an AM news producer. That was one of my first jobs, kind of essentially finding interesting stories and guests for am, um, news talk show. And I learned a bunch from this job. It's really interesting, like translating complex ideas and processes into stories that people can listen to in their morning commute. Yeah. And uh, I think, you know, around this time, which is 2010s, a lot of startups in tech were hiring people from media and journalism to become content marketers. So that's what I did. I got out of radio and landed a job doing content marketing at this tech startup. And I really knew nothing about tech at the time, but I was looking for a change. And I found myself at this company that happened to be enrolled in something called Y Combinator. And I had no idea what that was. This is around 2013. So I went down to Sunnyvale, California and I was just kind of exposed to this ambition and energy in Silicon Valley during this really big time of growth in the industry. And of course, you know, at this time I wasn't a programmer, but I was very much surrounded by, by all these programmers that are working so hard to build this tech utopia future. It was extremely exciting and it kind of intoxicating for me. I'd never met so many people that were so passionate about the things that they did. And I was like, wow, you know, that's so Cool. Must be nice to love your work so much. But I'm not a software engineer. I tried to learn programming a few times and I failed. So I was like, womp, womp, I guess I'll keep on doing content marketing. It wasn't until like a little bit later that my partner, who was also looking for a change, she started this coding bootcamp and she phoned me one day and she was like, hey, you know, I think you should quit your job and do this coding bootcamp thing. I think it's really fun and I think that you'd be good at it. So on a whim, I quit my job and learned Ruby on Rails. And you know, I've always been someone that likes to make things, but I never really found my medium until I learned to code. And so ever since, I've been infatuated with building products for web and mobile. And I was very lucky to get my start at Metalab doing just that. So I've been there for a little over 10 years now.
Speaker B: Okay. And you've obviously gone right through the ranks, right to the top of head of engineering, which is a little bit amazing. Yeah. Uh, fascinating. I always really love speaking to people because everyone's journey is kind of slightly different. Uh, it's obviously always different, but there is a theme and that a lot of people, and myself included, you kind of meander through and there's kind of like sliding door moments through everybody. So I always enjoy listening to people's stories from, uh, how they've ended up where they are, you know, so. Fascinating.
Speaker A: Yeah. Tech doesn't always seem like super welcoming, but it does. You know, there are people of many, many stripes kind of within this industry, which I think is nice.
Speaker B: Yeah, I think so too. Okay, so look, we're going to go straight into some of the meat of the topic. There's quite a bit to cover. So want to get into kind of what we're kind of classifying as kind of the journey of interfaces from mobile to AI. In a previous conversation, you've kind of described the, I suppose, trajectory from gesture based mobile interfaces, so taps, wipes, et cetera, to real time collaboration productivity apps, and then to, uh, Web3's trust through transparency. How have the core design principles learned from the mobile and productivity waves directly informed your current strategy for building successful AI powered products?
Speaker A: Yeah, so people's expectation of software I, uh, think has changed a ton in the last 20 years. And the big thing is that every wave of tech doesn't replace the last one. It kind of Layers on top. And it changes how we think, what we think software is, our reflexes, our habits, and in some ways, like the actual ways that we think about the world and make decisions. So this is to say that AI products aren't arriving in a vacuum, they're arriving into this landscape of layered expectations of what people think normal software feels like. So going back to your question, if you look at the wave of mobile apps, starting with the iPhone in 2007, it trained us on responsiveness. UIs that feel adaptive, like material that you can kind of push and pull and pinch. And mobile applications, I think also normalize something else. Mobile applications are imbued with cameras and microphones, sensors, location data, et cetera, et cetera. You know, when you download a new app or you visit a new website, it's very common to grant the application access to these tools and this data. So those are kind of some expectations from the mobile wave. Then we have the productivity wave notion. Google Docs, Figma, these apps built the expectation that software is real time, that it's collaborative, multiple people are in the same place seeing the same thing with history and versioning and like inline comments and things like this. These are all baseline expectations of uh, business applications that we use today. So when we think about AI powered products, a few things I think fall out pretty directly. So first we want AI systems that feel responsive even when they're busy or thinking. AI systems inference cannot always be fast. Tool calls take time, retrieval takes time, long generations take time, but the system can still keep you oriented. They can stream partial outputs, they can show status. In ChatGPT it says searching or drafting or checking. Responsiveness is about keeping the user in a state of orientation rather than waiting. So in this sense I think latency isn't just a performance problem, it can be used as comprehension time. So I think that's kind of the first principle that is really interesting to me. I talked a little about permissions and access. I think that the second is that we like to make permissions and access very explicit. The application tells you what it has access to and for what purpose. Because with AI agents I think the context window is very important. As a developer, I think very much about what's in my LLM's context window and I think non developers are getting wise to this as well because LLMs tend to perform poorly when there's too much in the context. This is commonly referred to as context rot or needle in the haystack problem. So one thing that we try to do is try to make Context super visible. What can the agent see, what tools can it call, what actions can it take, what safeguards uh, are in place? It's nice to know what an agent can do so that it doesn't accidentally shoot you in the foot or something like this.
Speaker B: No, absolutely. And are you working with enterprises? Because obviously there's a huge amount for the enterprise with regard to uh, security and safety and stuff like that. And is there just kind of trying to think from, I suppose your client side of things, is there things that they're absolutely requesting that just have to be there type stuff or all these kind of just purely based on kind of the trends that are usage is that the users are having, if that makes sense. I'm just trying to get a feel for you talked about a lot of the stuff there from a uh, UI UX perspective. But when you're actually helping design side of stuff, is there a kind of a set of standards now basically? Or are those standards being driven by kind of enterprises or the users, if that makes sense?
Speaker A: I think it's driven by kind of the context of the industry that you're working in. I have two examples with regard to this. Like we're working with a dating application right now that tries to replace a human matchmaker with some sort of AI agent. And we have to be very careful what an agent reveals about a person that you might be interested in, because you put a lot into dating applications about your personal life and your preferences and things like this. And when you're talking to a matchmaker about a potential match, we don't want to reveal too much or too little. And so when we're talking about safeguards, what data can the agent see, what tools can it call, what actions it can take? Some of that is user facing, but a lot of that is also, uh, just kind of on the back end. How we manage, how we orchestrate our agents. Something that is a little bit more visible is that we worked with a company that manages a lot of policy data in the United States. They have indexes of millions of policy documents, people, organizations, things like this. And a policymaker or journalist may kind of ask this tool questions like what has Coca Cola spent this year on lobbying? And you really want to be able to see the information that it's slurping up, that it's summarizing for you so that you can verify it. We don't just want the answer, we want kind of how you got there, because these things are very important and nuanced and we can't quite Trust agents to do that type of work.
Speaker B: Yeah, no, I get what you mean. Just moving on. So when we spoke previously we talked about kind of there's two types of products and we see this a lot at kind of development side of things. Like there is kind of existing products out there that are traditional kind of software now that they want to be kind of AI enhanced or AI infused. And then there's AI enabled. So AI kind of built native AI like they can't exist without there, they can't exist without AI. Uh, so where do you see the greatest long term market value being generated in transforming existing products into AI enhanced tools or really building entirely new AI ah enabled products from the ground up. And I think a lot of companies are struggling or really thinking hard about this at the moment. We certainly come across a lot of our customers that are being threatened by A and L customs that are thinking do they take their existing product and enhance it or they literally build from scratch. And we're kind of curious how you're seeing it in the market and kind of what your thoughts in around from a uh, business and ROI perspective.
Speaker A: This is a super interesting question because I think there's two ways to think about the greatest long term market value of AI products. Like we can look at the biggest aggregate value of these two categories or we can look at Power law winners where a small number of companies capture a disproportionately large share of value and everyone captures much much less. So AI enabled products, products that couldn't exist without AI, they have this advantage of creating and owning a category of product. I think Robotaxi is Waymo is an example of this instance. It's a service that can't exist without AI. AI education applications is kind of another example. Even something like Perplexity which is AI enabled search. You could argue that the AI system is at the center of the value proposition there. So these AI enabled products, they have different unit economics, maybe different network effects or different switching costs. And so AI enabled businesses might hit really big and dominate a category. But I think if we look at the biggest aggregate value, I think the clear winner is AI, uh enhanced businesses. Because these tools will diffuse across many existing productive sectors. AI will sit in the middle of where value already gets created and captured and we already see a lot of value being created in the space of developer tooling with GitHub, Copilot, or in creative tools like Adobe's Firefly, integration with Photoshop and Premiere. There's a lot of invention and innovation happening in AI technology. And AI products. But there's still a lot more diffusion across existing industries that to happen and people's reflexes and skill sets and company or structures haven't kind of changed at the pace of innovation. So to answer your question, I think like the existing sectors I think is where there's going to be the most kind of aggregate value. And so that's the way that I'd answer that question.
Speaker B: Yeah, no, and I think you're right because it's already in place basically and you know, if they, you know, infuse it then common sense would think that would become bigger. So what we see a lot is, and I'm keen to kind of get your thoughts on this. Like we see a lot of companies that are out there just to optimize basically kind of existing processes and sometimes they infuse AI to just optimize, you know, automate workflows or make things just slightly easier for the user, et cetera. We are insertus are starting to believe heavily in that uh, complete reimagination is going to be important. It will actually come. And the example that we always give, or what we're starting to explain to people is that uh, AI has got a lot of similarities to the introduction of electricity. Back in the late 19 uh, hundreds or 1890 or so electricity came. It was used to do things like electric frogs. Kind of the wow moments like a bit like write a poem in, in Spanish that sounds like Donald Trump or something like that. It's kind of like, it's interesting but it's useless, you know, so kind of that type of stuff. But where it became truly profoundly kind of valuable is when they use the example, we use the example of the Ford factory. So typically factories are all steam powered. They were built and organized in, around being steam powered and when they used electricity they just made things a little bit faster but like kind of transformational. When they reimagined the factory for the up and down based on electricity that drove immeasurable ah benefits. So a bit of a long winded way to say is like we as artists believe AI ah will be truly transformational when we reimagine kind of products, businesses, organizations. What do you think about that statement? And agree, disagree.
Speaker A: And I think that's an awesome comparison. I uh, think electrification is a really cool comp. You're exactly right. The ceiling on return on investment by integrating AI into your company without rewiring some of your workflows is limited. And like you said with electricity generation, distribution of technically viable electricity was kind of in 1880s. Right. And then it's widely adopted in industry by kind of 1890s. But you really don't see measurable economy wide growth in productivity until the 1920s. So that's like a 30, almost 40 year gap. And so that exactly what you're saying is what companies are wrestling with today with regard to layering in AI. So the question I think you're asking is like, why is there such a lag in productivity for electricity? And uh, your answer is like the bottleneck of real value and productivity wasn't the availability of electricity, but it was how organizations used it.
Speaker B: Yeah, we think that like people are the bottlenecks and like we can't actually. It's like thinking how big is the universe? It's like trying to reimagine the thing. And I like obviously we're using agents and for efficiency and for better personalization and all that type of stuff. I'm curious, are based on what you're seeing in the market is like is there an appetite for reimagination at the moment? Are you seeing any aspects of that or is it purely as you were kind of describing earlier?
Speaker A: Yeah, ah, it's slowly bubbling up through organizations that are figuring this out. And I think a neat story that is kind of tangentially related. There's this funny interaction on Slack the other day in our company, one of our senior engineers was asking one of our juniors, hey, what plugin did you use to convert these FIGMA variables into code? And the junior says, oh, uh, I didn't use the plugin. I screenshotted it and asked ChatGPT to write some code. And I think our uh, reflex is to think about things in deterministic procedures. You know, workflows and plugins and integrations. But AI makes many different workflows possible. And so those are. Some of that stuff is grassroots. It's changing your reflexes, changing your habits. I don't think that I'm not aware of organizations that have really figured this out, that have done the electrification thing where you're not just replacing a steam engine in the basement of your factory, you're really redesigning the, the layout of your workspace so that you can build these efficient pipelines, these efficient workflows.
Speaker B: Yeah, no, and we would agree as well. And because if uh, you think about it, why would you unplug everything or rebuild uh, everything until you were uncompetitive or you're threatened or there was something really, there was enough pressure for it to happen. But I think it will happen at some point. But it's kind of an interesting and I'm asking a kind of question purely from the like, what are you seeing in the market? Because we probably about very, very tiny percentage of our customers are brave enough or committed enough to kind of do something like that. And it's generally when they are threatened by AI, uh, and they have a competitor or something that has kind of really been the driving force behind it. And I think coming back to electricity, that transformation took 40 years. We're what, two, three years in with the AI side of things. It will be a lot quicker than 40 years, but we're still at the very early stages of it. But when you think about it, it's kind of an interesting and a very exciting time where we're at, if that makes sense with it, because we're on the journey with it. But we've got a lot of way to go basically because the whole reimagining how everyone works and how we do things is coming really as far as we can see.
Speaker A: It's absolutely exciting. I think at the highest level the breakthrough really came from what you said is organizational innovation, not this kind of electricity generator. And in the case of steam powered factories, the benefits required starting over as opposed to an incremental change in the structure and the workflow of the company. So that can be a little scary.
Speaker B: Yeah, it is, it is and it scares everybody. But I think the people down in San Francisco will no doubt do, will probably be the pioneers in it anyway, as they always are. So interesting times. You kind of touched on one of your colleagues using AI, uh, in development and you previously advocated AI agents acting as an analog to pair programming and kind of an ever patient kind of entity as you kind of say, that accelerates a single developer's workflow. We're seeing a lot of this by the way, we're using CLAUDE code and that and we think it's incredible. But from your perspective, what are the key limitations or problematic parts you see in the, you know, the alternative approach? I think you mentioned Google's anti gravity concept where human managed a large number of AI agents. And why do you believe the one to one pair programming model is superior?
Speaker A: Yeah, I mean the problematic thing about managing like half a dozen or a dozen agents is that they produce just a lot of code. And reviewing and merging at uh, the pace that coding agents can produce is a lot to keep in your head, but at the same time the pace that models and AI harnesses are improving is really astounding. And I've been impressed with what I've been able to kind of one shot with AI, uh, agents. This is to say that my opinion about this is kind of mixed right now. You know, on the one hand the productivity gains of controlling multiple agents at once is awesome. And then on the other hand by gaining that productivity I think we lose understanding team alignment and conceptual integrity of the systems that we're building. So realistically there will be tasks that are better suited for one method over the other. You may send a few agents off to fix minor bugs, implement lower complexity features or chores, while you use another agent as a pair programmer for something that is maybe more complex.
Speaker B: Yeah, I think you're right. I mean I think they're, we're going to come back to we are still the blocker or the bottleneck in this as any humans are, because you can, you can get them to do so much. But we're going to come back to things that are critical. Humans are still going to need to review them before put like code into production, all that type of stuff. So it's an interesting one, but I'll come back to that. I think we're using the parrot programmer from uh, like existing workflow perspective. I think there's going to be a complete reimagination in around what had actually happened. But I think we're, we're probably still a little bit away from that I think purely because there isn't that deep trust yet into let's say the quality of what I can actually do. But that will probably come back to in a bit of time. So the coding agents have kind of come in and you kind of touched on a couple of times that the engineers enjoy being in the code and solving problems. But now they've got kind of like this tool that does a lot of the stuff that they love. So I suppose how do their enjoyment, their morale, is that kind of being going to become affected as a consequence of these new tools that kind of, in a lot of ways kind of take away some of the stuff that they're, you know, they're inherent problem solvers, they like to do it themselves. That's where they find the enjoyment of it. Do you see that as kind of like a big issue in any way?
Speaker A: Yeah, I mean I think AI makes code cheap and it's a little sad because it's a joy to writing code and it's certainly something that I miss as someone whose core function isn't committing code every day. But there's also a great pain in software development and it's not always typing. It's this kind of emotional drag of being stuck. You get this vague feeling of uncertainty. There's context switching. There's this feeling that you're on the clock and you're burning time. So AI agents a good collaborator, let's say AI or human, helps you kind of externalize your thoughts and test your hypotheses and helps you regain momentum. And that's the benefit that I felt from using AI as a pair programmer. I'm way more deliberate in my thinking. Like I can articulate my intent, constraints and trade offs like I would to a coworker. And I'm also way more open to small refactors because they're easier to do and test out. Refactors are exploration. Like you're not really sure that it'll work until you get to the end. You're like, oh, uh, that's actually kind of the same problem that I had before. And so it's nice to have less friction when you're doing these types of things. And it's also a great way to expand the type of work that you can do. It's a great way to learn new programming languages or frameworks. When I'm learning something new, I'm very concerned about doing things the right idiomatic way. And so AI is a huge help for me there. And so I think you trade off this kind of, this joy of coding for this joy of learning and creating and, and feeling very productive.
Speaker B: Yeah, no, absolutely, I think you're right. I mean it's in like there's, we might be taking away something. It's giving back in a lot of other different ways as well. So, you know, the ability to do more and to uh, uh, I think there's uh, a lot of satisfaction in that as well. So I think there's a lot of core skills that will drive that for sure. You mentioned the idea of LLMs and cognitive tools being similar to search engines, which kind of help humans better find and process information. I'm kind of curious, is that like, what do you think is the biggest set unsolved problem in their product development or user experience? You believe the next iteration of AI interfaces will successfully conquer.
Speaker A: Yeah, I think the most important fact about LLMs being cognitive tools is that their outputs can be very fluent, but they're not actually grounded in reality. It feels like LLMs are more and more capable every single week. But hallucinations seem like an inherent property of large language models. They can just be unreliable and the content that they generate can Be inconsistent with the sources that you give it, the facts and even the context that you provide it. So this is not just a model issue, but I think it's the interface and a workflow issue because LLMs sound fluent and confident and that can produce a lot of over trust. When an LLM provides a suggestion, people may be kind of less vigilant and accept it even when it's wrong. And this is a huge kind of unsolved problem. Users, they don't need just an answer. They need to know why it's true, what it depends on, what could change that answer and then what to do next. So this is very much, I think, an interface problem as much as a model problem, because trust is created or destroyed by what the product makes visible, its sources, its uncertainty, its assumptions, and the ability to verify through the interface. So that's still a problem that I think is unsolved.
Speaker B: Yeah. And do you think that is it even possible for LLMs to build in that like we, you know, this response is like 50, 60% uncertain or whatever. Because you're exactly right. I mean like one of the biggest things holding back is like that lack of trust. And the lack of trust is there because there's degrees of inaccuracy there as well. So. But how do you actually solve that? I mean, uh, and maybe that's just, it's just not been solved. But you think that there should be a solution for this given it's such a big problem for them, you know. But uh, maybe that's just. That is the point, that there isn't a solution.
Speaker A: Yeah, we have technical solutions. You know, REG is technical solution retrieval, augmented generation. We use vector storage for this. But I think knowledge databases are growing trends. So graph, like graph databases. Graph REG is the potential solution tool use reasoning and acting loops, things that you can kind of inspect. But certainly these are solutions that we have today. But there's still a lot more work to be done.
Speaker B: Yeah, I think we broadly think is like you can, they're just like hallucinations are just a feature of LLMs just because of how they're being built basically or how they're being designed and built. But you can significantly reduce them I think. And that's certainly we're seeing it at kind of an enterprise level, but there's obviously taking it from one layer to like minimized hallucinations is quite a lot of work and quite a lot of expertise involved in that. And maybe that's just where we land. Unless they kind of redesign LLMs to be something else, but I don't see that happening anytime soon. So LLMs are getting better and smarter. Like, where do you see kind of like that one uniquely human element that will become the most valuable contribution to product development basically, is in, like, what's going to be the key characteristics as product development kind of evolves, basically, particularly with LLMs.
Speaker A: I think from a software development perspective, what matters more now than ever is strong architecture, very clear intent, technical leadership. The greatest leverage for engineers won't, of course, be the fastest coders, but people who can frame problems well, guide AI output and kind of preserve this conceptual integrity of the system that you're building so that people, not just machines, can understand it. I think at a wider level, this idea of play, I think, is really interesting to me. LLMs don't play the way that people do. We get joy from moving our bodies, excitement from discovering something, satisfaction from accomplishing something. And the thing I think about sometimes is some of the really formative technologies started as toys that we played with. And an example of this is the early telephone. The early telephone was seen in some ways as a parlor trick, kind of, uh, a scientific curiosity, something that was useful for entertainment and casual conversation, but really not for commerce. And this is because the sound quality wasn't very good. You could really only go short distances, and people didn't really understand why you would want to talk on the phone for business purposes. And dreaming up these types of experiences is probably uniquely human. I hope so. The ability to play, to evoke emotions in humans that tell you that this is the right thing to build for these people in this moment, in this specific context, I think, like, that is something that is a uniquely human element that we bring into product development, that LLMs can't just kind of inference away.
Speaker B: It's kind of like the visionary aspect of it as well, is being able to orchestrate. I would agree with you for sure. Do we think AGI is possible and probably sitting in the camp that's not. And I think that's kind of our unique human element of that you articulated really well. There is like, play. Yeah. Uh, but I completely agree with you. We always finish with really kind of getting a download of, like, you've obviously had a very interesting career starting off media and then moving into tech. Like, what are kind of the resources, be it book, podcasts, et cetera, that have shaped your thinking, not just in around kind of leadership and where we are today, but kind of really entering kind of like your field or in technology, AI, ux, et cetera.
Speaker A: Oh, I mean, specifically around AI. I love this essay called. I think it's called AI as a Normal Technology. It's this idea that you're touching on that AI is a, uh, normal technology, like electricity is what we would consider a normal technology. It's not AGI. So this essay, I think, is really, really good. I would recommend reading it. In terms of leadership, I think there are some classics. Like, I love this book called Managing Humans by Michael Bopp. It's great, it's funny, it's very easy to read. In terms of organizational design, I like this book called Team Topologies. It has great ideas like Conway's Law, which is. It says that the design of a system reflects the communication structure of the organization that built it. So in other words, if your company has three teams or something like that, you'll end up with a product that has three modules. And if those teams don't really talk to each other, those modules won't talk to each other either. This is very interesting to me. Like I was mentioning earlier off the mic, I'm, uh, a parent to two young kids and surprisingly, parenting content translates pretty well to work in leadership. So I love stuff from. Yeah, exactly.
Speaker B: Yeah. There's a very good book. Can't remember the name of the author now, but it's. I think it's along the lines of, like, how you lead your life, basically. Like what you want to be remembered as a. I'll have to dig it out and share with you. But a lot of it is the thinking about. It's kind of actually like thinking of your family as, As a business as well. Like, stay with me for a second. But it's like having family values and having a kind of a mission. Like, this is what we're about. We're like nice, kind people. We do good things and all that of stuff.
Speaker A: So.
Speaker B: And obviously I was working before I had, uh, a family, but like, the similarities of how you manage your people that you work with or workforce, etc, with regards to your family, there's. There's a huge amount of overlap. It goes both ways.
Speaker A: So absolutely.
Speaker B: I can completely relate to. It's a great point. Thank you so much. It was really, really interesting. It's definitely a fascinating area and I think one that's got a long, long way to go, and it's just fascinating. Thank you for coming. Speak to us.
Speaker A: Yeah, thank you, Ricky. Thanks for having me.
Speaker B: The Story of Software podcast is a Zartus production brought to you by Adnan Tukar and Lariana Fantoni.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.