Hosts Andrew and Justin are joined by Microsoft's VP of Developer Community, Scott Hanselman, "Chantastic" Michael Chan, former Chromatic developer and incoming WorkOS team member, and Yuna from Google's Chrome team.
The panel focused on the key roles and functions of Developer Relations (DevRel), emphasizing its significance as the bridge between product developers and the user community. The panelists highlighted the importance of empathy and efficient communication in DevRel, and described this role as the backbone of the product development process.
The discussion also touched on the concept of "level privilege," which refers to the ability of senior engineers to freely voice their opinions. A crucial point that emerged from this is the importance of clearly defining and understanding the roles and objectives of a DevRel position.
The conversation then shifted towards the transformative potential of Artificial Intelligence (AI) in web development and developer education. Panelists predicted a shift in learning methodologies brought about by AI and explored various applications of AI, including debugging code and prototyping user interfaces. However, concerns were also raised regarding AI's ethical implications in academic settings and its environmental impact.
The discussion concluded with reflections on the democratization of creativity enabled by AI and the role of inherent difficulties in the creative field. Overall, the panelists provided an insightful discussion on the evolving dynamics of developer relations and the future of AI in web development.
Share this talk with your friends
Transcript
Hello, welcome to the DevTools FM podcast.
It's a podcast about developer tools and the people who make them. I'm Andrew and this is my co-host Justin. Everybody, this is a little bit of a different scene for us, so we would like to thank our panel for being here. We are at the Epic Web Dev Conference and really excited to be here.
So what we're going to do is just give our panel an opportunity for each of you to introduce yourself and to kind of tell us a little bit about the work you do. And then we'll dive in and do some questions and that'll be it. Yeah. So, do you want? My name is Scott Hanselman. I'm a VP of Developer Community at Microsoft.
I've been programming professionally for 32 years. I remember when the internet was there and I was there for eternal September. If anyone remembers that. If you don't, go and Google with Bing for eternal September. And yeah, I work on DevTools at Microsoft.
Hi, I'm Michael Chan, Chan or Chantastic, I answered you all of them. I am in between jobs. I'm fun employed right now. I just left a position at Chromatic doing developer experience type stuff. And I am headed towards WorkOS to do developer education.
So super excited about that. I like making videos as like a final stage of my learning process. It's been something I've done for like, I don't know, 15 years I've been in tech. So yeah, that's a little bit about me. Nice. Well, hello. My name is Una, like unicorn.
And I currently work at Google on the Chrome team focusing on web platforms, specifically UI features. I also, you know, do a lot of work with DevTools to make sure they're supportive of those features. Before this developer relations job, I was working in front end for many years.
So doing UI engineering, front end development, kind of that intersection between design and code. That's kind of where I find my happy place. So that's me. Yeah, sort of started doing like the community stuff before it became my job, which was neat. And now I get to do that for work.
So as dev rels, you're like the first line of defense before the developers, you meet the community where they are. So in that, how do you handle the community feedback? I'm sure there's a lot. And then like, once you take that feedback, how do you communicate it to the engineering teams?
And then have you championed a feature from that community feedback that you're proud of? I mean, I can go first. Y'all are deliberating. Yes, I love community feedback. The reason I like going to events like this, because I want to hear about what you're working
on, what you're struggling with, what you're frustrated with, what you're excited about. All those things are so critical to making sure that as we build for the web, the web is supporting the users that build for it. It's as simple as that. So like a huge part of my job is making sure that we're working on the right things. We're prioritizing the right things.
So the things that we're landing make sense to developers who are using them, that they like the solution to the things and that they can use them. So I really love feedback. Please come talk to me if, you know, if you're listening to this, you can always message me. You can, you know, send a message on Twitter, DM me, send me an email.
I really appreciate the user feedback. And then we bring that to our team, whether it's qualitative analysis, like talking to developers, like bringing back quotes, bringing back experiences, or quantitative, like we sponsor surveys, like the state of CSS and those sort of things. So we can get more aggregated data.
And then we use that data to really make decisions on what to prioritize, like how to kind of focus the work that we do in the future. It makes a big difference. I don't think the developers realize how big of an impact it has. Like talking to the DevRel team, the engineering teams, like that's how you make change work for what you need in the ecosystem. So definitely.
Love it. Yeah. I think that's a perfect answer. And I'd like to add to that, because I think that there's, in terms of how you roll that feedback back, it's very team dependent, like everything's, you know, it depends. But I feel like a lot of it is like context application, because the world is very unkind.
And I think that, you know, we develop these shells around like the things that we've built. We're very protective about them. We like them. We have our reasons. And so when people come in, you know, from out of nowhere and like really hate this thing that we're making, it's natural to be defensive. And I think a lot of times, like the engineering teams, like, you know, will feel that faster.
And like having that kind of like layer of tissue in between the like DevRel layer is really helpful, because we can have this like disconnect about it. Like, well, we didn't build it. Like, we just want to make sure that it's best for everybody. And at least, you know, that was my position.
And I think that a lot of it is applying the right context and being able to communicate that in a way that's softer, that communicates the things that you understand. Like, I understand that we're trying to get here. And this is the future. And this is what we're trying to build. And some of these things have to get sorted out first. But like, this is still something that people want, right?
And if we can meet them, like even a little bit, like we'll be able to indicate, like to them that we care about what they care about as well, and like meet them somewhere in the middle. And I think that that's kind of being that buffer is a little bit challenging, but like a really fun part of the role sometimes. Yeah, I agree with everything that you both said.
I would add that it's an exercise in extreme and ongoing empathy. And it is a marathon, it's not a sprint. And it is helpful, in my experience, that a dev rel focus on the dev as much as the rel.
Because, you know, if you've just got it started, maybe you came out of college and went directly into dev rel, but you've never like carried the page or run a run a live site, your empathy is going to be slightly different. But when, you know, the, I don't know, chief architect of Little Debbie Snack Cakes has a site down, and you're like, oh, man, I remember what it was like to work for a company that,
you know, a thankless job and the site's down, I really feel that in my chest. So all these years later, you know, when someone has a problem, yeah, the telemetry says it's only 3% of users or 1% of users, but it's 100% of that guy or gal who's having that. And I really feel responsible.
It gets me in trouble, though, sometimes, because, like, Microsoft, the company I work for, and I'm sure you must feel this way about Google, like, I can't own all this stuff. Like, dude, my Minecraft account, really, I feel it for you, I really want to help you, but it's not my space. You know what I mean? Like, I get emotionally attached to solving these kind of problems.
Sometimes I'll do a PR, sometimes it's about raising a bug, sometimes it's confirming with telemetry that this is, in fact, a bug and not an outlier. I would like to transition a little bit and sort of just talk about another part of public communication, which is just education.
I mean, as a public figure, and you're talking about tech, either a product or representing a company, like, part of your role becomes education. And it's interesting to think about the tech industry, especially now. So the tech industry has went through a lot of different waves.
We had the dot-com boom and bust, and then we had, well, bust, yeah. Then we definitely had, you know, there was a hiring boom during the pandemic, and then as interest rates rose, we definitely have had to experience a lot of layoffs.
And so it's an interesting time to be in the industry, and especially for people who came up during the boom who are new to the industry. So how do each of you feel about the state of the industry as it stands today? And then if you are talking to someone who's considering joining the industry, what do
you say to them? Respectfully, I think there's three different complicated questions inside there. There's the state of the industry, there's advice for the emerging person, but I want to talk, for my answer, about education.
I think that the job is almost entirely education and advocacy, which is itself being a teacher. I've always long wondered, like, what's that tagline, what's that Twitter bio, what's that resume thing that you put? And I've always just put teacher. I was a teacher at Portland Community College, and I was a teacher at Oregon Institute of
Technology, and I am professorial in my presentations and in my style. I bring big dad energy to everything that I do. And in doing that, I am trying to make you successful because my teachers, the ones that I remember, the teachers that I still talk to now, 40-plus years out of school, the teachers
that came to my wedding, the ones that you see, like, at the shopping, you know, this grocery store, and they're like, oh, my God, Mrs. Johnson, you said a thing in 1984, and you changed my life. That's who I want to be as a DevRel, is I want to be their favorite teacher. And in doing that, I will advocate for their best interests, and in doing that, you know,
the bug will get fixed, or the product will get shipped. That's a very sweet sentiment. I like that a lot. I say I'm a web developer like Tim Berners-Lee says, so I aspire to be like him. Yeah, I think a big part of the role is definitely education. I think the advocacy part is also pretty critical, which we sort of talked about in the first,
you know, question. Yeah, there's a lot of questions that are sort of being asked there. The state of the industry is really interesting. It's in a place that we haven't seen in a couple years, probably, like, at least the last 20 at this point, and it's hard to say.
I think the advice that I tend to give, if you're new to the industry, is how do you help your potential future employers understand who you are, what you know, how you learn, and sort of on this thread of teaching, how you teach. So I always give the advice of, if you're new to learning, if you're in a boot camp,
or if you're learning in school, write a blog, keep a blog. For me, that was like public notes that I was kind of taking when I was still in college and I was an intern, and, you know, I wrote about when craft CMS was new, how to set up craft CMS on your Mac, and then I was able to talk to, like, the developers of a craft,
and they ended up linking to my little intern blog post in their official documentation because nobody else had written about it yet, so I was like, wow, this is cool, and that for me is also how I got really involved in community, which is the second thing, keeping a blog is important because it helps you to kind of remember what you learned, to kind
of teach people what you know, and to learn it better because as you write or as you teach, you remember a concept more, so if you're learning, that's a great way to kind of showcase your skills, but also learn skills, and then also it helps you become a part of the web community because when you start sharing your experiences, your demos, your explorations,
that's when you have something to talk about with other people, and I feel like the community is so important. I've gotten all the jobs I've ever had in my career somehow through the community, and it was either from meetups, where I remember being an intern going up to the speaker, being like, I want to work for your company, how do I do that? They're like, you're too young next year, you know, here's some books to read in the meantime,
so I think that that's the thing that you can do is really get to know people, embed yourself in community, and it's a lot easier to find a job when it's, there's a person there, it's not just like a resume that's being floated into the ether, so yeah, it's a tough time in the tech community, but there's still things that you can do to make yourself
stand out and become part of the ecosystem around you, and those could also be virtual communities, it doesn't have to be, you know, in person, although I think meetups are great, there's a lot of stuff you can do out there. Yeah, I love that a lot, and I want to piggyback
on that because I, like, have recently been affected by the kind of shrinking DevRel space and kind of the fact that things cost more all of a sudden. I think it's an interesting time because, you know, with the zero interest rate phenomenon, you know, you get paid to
learn and now you really have to bet on yourself, like, you are the one who's paying and investing in those things, and I agree, you know, with everything that you said about creating and showing people what you're about. A friend of mine called content interviewing at scale,
and it gives you an opportunity to put yourself out in front of people who are going to be making decisions about you in the future, whether that's to accept your conference talk or to invite you on the team or to, you know, there's so many opportunities, like, where people want to see you just communicating an idea, and when you do that well, it's like
magnificent. Yeah. Could I impose upon you to expand on the definition of what the zero interest rate phenomenon is? Because I don't think everyone knows that meme. Yeah, yeah, yeah, sure. You know, I'll explain it as best as I can because I don't really know. I just know it like the meme-y version,
but basically, like, you know, for a long time money was free, interest rates were low, and so there was a lot of money to draw from and then kind of invest into bets that were maybe higher risk, I guess. Research and development. Research and development. Yeah, yeah, yeah. Research and development. And so, you know,
in my case, like, that bet was, you know, my employment as a person making sense to the bottom line as, you know, of a company. And I think that there's ... I don't know. I would love to hear what you think about this, but, like, part of this is, like, who
we are. Like, we have this thing in us that wants to be a part of community and engage in that way and share back in the way that we were impressed upon by the people who meant a lot to us. And I think that there is a flashy side of DevRel, and, you know, over the past
few years where people are like, oh, I can, like, travel the world and, like, get paid to do it and talk in front of people, and, like, that's really awesome. I think that is, like, that part of it is gone, and I'm excited for the people who will press through now, because I think those are the people who really, like, love it the way that we
love it. But I don't know. Maybe I'm making assumptions. I think it's also worth noting, and this might be a career limiting thing to say, but DevRel people who fool themselves into thinking that they're not sales and they're not marketing and that, like, you know, I'm the people's programmer. I'm here to help. I don't like
that I am indirectly being asked to sell a thing for a giant company, nor am I excited about doing any kind of marketing, but I sleep like a baby at night because I am educating people and I am genuinely excited about the thing, and if indirectly a sales or some marketing
happens by virtue of my actions, then that's how I kind of justify being a cog in the machine, but I'm just really excited about the cogs that I happen to be selling, if that makes sense. I used the example in the speaker room earlier about people who knock on your
door to convert you to their religion, and I love that for them. Have you heard the news? I am excited about my things. I'm excited about the platform. I'm excited about the open web. I have been consistently open web since Jump, and I'm never going to stop, and if you ever see me, like, get fired or leave my company, it would be because I'm either
retired or they don't care about the open web anymore. Does that make sense? And that authenticity allows me to still acknowledge that there's sales and marketing. It's a function. OKRs, blah, blah, blah. Man, I want to disagree there a little bit because... Let's go!
No, no, I hear you. I think that the part that I disagree with slightly is that DevRel is more tightly aligned to sales and marketing. I have been doing this type of work before I officially became DevRel for many years, talking about CSS and UI at web conferences, and yes, then it was because I wanted to travel.
That's education. That's you as an educator. But I don't see it as, you know, trying to sell someone on a feature. I see it as, hey, I thought this was really valuable. I think this is so important. I'm really passionate about it. I want you to know about it so that it's an option in your repertoire, like, so that it's... That sounds like we agree, though. It's like, have you heard the news about the web platform? Yeah, but I don't really look at it as...
But you're selling Chromium. Not really. I don't really specifically talk about, hey, this is a Chrome-only feature. You should use this in Chromium. I talk about the web platform. I do not like when a feature is Chrome-only. I can't wait for it to go stable. I talk about baseline all the time. It's about the web platform. It's a free thing. Okay, so let me ask you this, then. What happens when the giant capitalist machine says, hey,
you know, talk a little bit more about Chromium? You just say no? That's a different job. I think that's a different job, and this is why I wouldn't do DevRel everywhere. I think DevRel is very different depending on where you are, and I think that, you know, what I see... The work that we do is very much, like, about the open web and about making sure that developers have the tools they need to succeed, but not every
DevRel job is like that, and I... That's very true. I think we 95% agree. Yeah. I'm all about coming to compromise. I don't want to have beef with you. No beef. I agree, though. Like, being at a smaller company, because you both are at gigantic
mega companies, and so, as you said, that's like a different role. You can kind of, like, separate that out into, like, these are people who, like, sell Chrome, and these are people who advocate for, like, developer experiences and whatnot. I think that, you know, just
as a counterpoint, in smaller companies, it does end up... That line gets very hazy sometimes, and you know, you really do have to know what you came in the door for to know, you know, what you're going to leave on, too.
And I don't think that's a small versus big company thing, either. You know, big companies, you also have dev rel who are focused on selling a product, especially when you get into, like, the paid tiers of things, which is totally fine, but I fully agree with you. I think it depends on the role, knowing what you're getting yourself into, and having the
expectations really aligned with your interests. There's nothing wrong with doing a more sales-oriented dev rel position, but it is a little different than, I think, you know, some people view dev rel... Anyway, it depends. So many, it depends. Well, and also, based on the size of the company and your longevity in the career and your
level, there's a thing we don't talk about enough, which is level privilege. Your privilege as a senior engineer or staff engineer, like, what you can get away with not talking about. Like, I'm going to give a presentation later today about AI. And, you know, I work for a giant company that wants everyone to use AI, and they want to spin the AI meters so
that money comes in. But there's things that I fundamentally disagree with. So how do I talk about the things I like and not get fired for the things that I don't like? So you got to hold your opinions. You know, I have actually been in a dev rel role at Google where I did not agree with the product at first. And so I came in there thinking, hey, I have all these ideas to make
it better. You know, here's my design doc, and we can improve this, improve the performance, et cetera. And that's not what I was hired for in that role. So I ended up leaving that role and joining the Chrome team and focusing more on a team that wanted that developer feedback that you were talking about at the beginning, that wanted to have input to improve
the product from developers. And I found a really stark difference in the kind of role that viewed dev rel as a outgoing go-to-market team and a role that views dev rel as a full cycle part of the process. I have to talk to that specifically because I think you're so right. And it's so important
to know exactly and re-clarify that, too, because I joined the Chromatic team and the charter that I was given was to connect Storybook with developers, right? Because it's really popular with design systems and component libraries and all that kind of stuff. We wanted
to actually get into the more developer-developing component space. And I think there's some really interesting tools there. What I didn't realize was that the intent was, like, take this to developers, like that go-to-market phase like you were talking about, and not bring back what the developers want
into the product. And knowing where you stand on that is so critically important to your happiness and everyone's happiness, right? Because if you think your job is to be like, this is what developers want, let's build it, and it's not, like, everyone's miserable.
This is why I sort of, well, whenever someone's like, dev rel is marketing, I'm like, no, dev rel should be a part of product. Dev rel should be more aligned with engineering. It can have a go-to-market aspect, which product is involved with go-to-market. But I don't know, at least I don't think of it as, like, more aligned with sales, or should be. And
maybe that's why dev rel is getting a worse rep today than I think we have in the past. Well, I think we smell it. Dev rels are known to, like, smell marketing and go, that doesn't smell good. I don't like that. So I didn't mean to imply that it was a sales and marketing function. I am saying, though,
that one is fooling themselves if they think that they have no relation to sales and marketing. But it's a three-legged stool. Yeah, totally, totally. Yeah, definitely. And on the product side, I really love working with some of the folks that I work with at Microsoft who are like, I had no idea. Like, you found a gold mine
of, like, feedback. Like, people who are really jazzed about good feedback, because it's like, this is how we thought it would be used in production, and this is how people actually use it in production. And, like, we had no idea. So whenever I, there's all the data, there's telemetry and that kind of stuff. But when I discover what I've always called
dark matter developers, dark matter is this, you know, I've been talking about this for 20 years. Okay, so dark matter is the space between the stars. It can't be seen, it can't be measured. And, you know, for every one person who's like, WTF, Microsoft with a dollar sign on Twitter, there's a thousand people that are not on Twitter who are not having
those bugs, or they're not talking about those bugs, right? They're anonymous Redditors, they're on Discord, they're in the dark web. And Twitter is not product feedback, right? And we've got all these, like, young, emerging dev rels, get a couple hundred thousand followers on Twitter by asking open-ended questions about what's your favorite JavaScript framework.
And then they go viral, and they call that dev rel. And it's like, no, go and find somebody, talk to the person on the BART that you overheard using, you know, whatever framework, and go and visit them, do call downs, show up at their house, you know, have you heard the news? Like, that's dev rel. Yes, snaps for that. Thank you. I got snaps.
So we live in kind of turbulent times for developers, like there's this new thing called AI that's doing a lot of things. And it's changing how we learn how to code and how
we learn new products. So how has the way developers learn changed throughout your careers? And how do you think it's going to change in the next five?
Stretch it out before you get ready. When I was a boy, when I was sitting on my BBS, on my bulletin board system with my X modem and my my US robotics modem in my parents' basement,
I would have a question. And there were only two books, right? There was like the KNRC book, and then there was the assembly language book. And if that was the sum of all human knowledge, and there was no other available information. So I could log into a BBS and leave a note. And then in like, six to eight weeks, someone would find that, you know, question,
there was no search, there was no Meta crawler, there was no Alta Vista, like, Lycos was not a thing. There was no you were alone, there was just this profound sense of grind it out. And then community happened and CompuServe and forums and usenet. And the idea that you if you choose to be you are never alone, you know, you will always go and Google with Bing
to find the question, and then discover that it was you who asked it years ago and answered your own question, you know, like that, that sense of never being alone is really amazing. Now, in the AI world, you have an opportunity to have an infinitely patient friend to ask questions of
at two in the morning on a Tuesday, and interview them. In my opinion, too many people are trying to get the AI to write the perfect for loop. And oh, you didn't write it right. And then ask again, and then ask again, I interview, I want to show this in my talk, I interview co pilot,
and I do it with my voice, I do text to speech. And I just have conversations. And at the end, it's written a book. And it's 85% correct and confidently wrong in other places. But the idea that I could have a tutor with me available, and whether it be co pilot, which costs money,
or you know, continue.dev, which is free and local and can be run in airplane mode, you can have whole conversations about your code with it means that rubber ducking you familiar with rubber ducking, right, is now a real thing. And you can vibe with a peer a pair programmer.
That's a thing that we have yet to explore is an infinite book of an infinitely patient tutor that I can ask questions about my code to I love the framing that you give for AI as a rubber duck. Because I think that there's a lot of potential there, especially when you think of
it as a co pilot as a assistant as a friend. The thing that I worry about with AI a little bit is, especially newer developers who haven't fully, you know, learned a concept yet just taking AI, you know what it says verbatim. And then when you get to that point where you're talking about you
have an 85% written, you don't know how to debug what's wrong. Like, how do you find the thing that is missing when it's valid code, it just doesn't really work for what you're trying to do. And that's kind of like, you know, the next phase, I think, and also just as a side note, because I
work in the CSS space, AI is particularly not good at. So we have a ways to go, which I think, you know, there's things that we could do to improve code quality across the platform. But I have a question. Yes. So I've used this analogy for years, I'll run it by you. What do you do when
Uber and Lyft exist? But I want people to learn to drive a stick shift, because it will make them better drivers. Change your oil, change your tire, drive stick once. I'm not trying to keep cars. I want everyone to have transportation. But when two people like are sitting on the outside, you know,
like sitting on the side of the road with their broken self driving vehicle, and they have no idea what a wheel is. I, as old man who shakes fist at cloud, keep finding myself saying, let's go just find the layer that you operate at and go one layer below. Just go slightly out of your
comfort zone. I'm not saying, you know, you don't get a garbage collector until you write assembler. I'm not saying you don't get to use Lyft until you learn how to drive a stick. But I am saying get a little uncomfortable and go a layer below. Oh, I hear you. I'm definitely not, you know, not saying you need to learn the basics before you can
use AI. But I'm never debugging my Uber. I'm never back there trying to fix the engine. You know, it's not my job to drive someone from point A to point B if I'm taking an Uber. That's someone else's job. They better know how to fix their engine if they break down. Yeah, exactly. As the driver, as the developer, I just think that you can get yourself in a place where you can get stuck a little bit more
easily, which is a challenge to solve. Oh, man, you both look at me. I like the I like I've always liked that idea of going one level deeper.
There's a I just watched Kung Fu Panda four with my kids. And there's a scene where we're Oh, man. Okay, there's another movie. There's another movie that I'm going to spoil it anyway, because it's the same
scene. But there's a there's another movie, shoot a big, big hero six. And someone's caught in a cage as they're trying to get out. But it's like, you know, it's too too hard for them. And they realize that they have enough strength to go under the cage, you know, go through the ground like a layer
below. And I think that that has always been. It's great, right? Because like, you can't get out in the trap that you're in. But if you can get if you can get under it, and then you that's the way out. And I don't know, I mean, like, I have a lot of like, weird thoughts on AI. I don't know if this is the right
format for this. But like, I like I'm not, we'll get we'll get drinks later. Like, I'm not afraid of the idea of like, intelligence being separated from humankind, and then it outliving us like, it's not something that terrifies me.
So this is this is where AI is not AGI. AI is just, you know, if you and I know each other long enough, we're going to finish each other's sandwiches. You're wrong. Dang it. I was hallucinating that one. You know what I'm saying? I'm just pointing out though, that like, it's a rubber duck because you're
talking to yourself. Yeah, yes. There's no one else there. You're alone talking to the thing. Someone told me that they were like, I'm a prepper. I'm going to prep for the apocalypse. And I prepped by downloading Mistral, which is like an eight gig, you know, large language model. And they said, and I
basically downloaded like, you know, the entire internet. And now I can just ask you questions offline. I'm like, Oh, sweetie. Download you want it like if you're prepping get a raspberry pi and download the Wikipedia but do not eight gigs is not going to give you anything. Imagine a whole world
that's been like, rebuilt after the apocalypse on one of these like, little large, like little small language models that runs on your Nvidia card. Think about all of the confidently wrong information that is going to be spewed out by these things. And no one's going to know what's wrong. Yeah, I like this idea that it's all a hallucination. And sometimes it's correct.
How did we get here? I think for me, my favorite use for AI is doing something that I in theory know how to do, or mostly know how to do, but it just you gotta, you gotta write the code. And sometimes, you know, I think that during the tailwind talk was great, because he was like, you know, you're not
prototyping a button, you're prototyping interface, I'll be like, all right, AI, just write all the logic. For me, I'm not showcasing that I'm showcasing the UI. It's yada yada yada. Right. It's from Scheinfeld. When you have to do something like that. So that's where I think it really shines. If that's kind of like the going level deeper, like, you know how to do it, it just will take you a minute. But when you
have some, okay, so then what do you do now where we've got people, you know, writing essays entirely and cheating on homework and like all that kind of stuff. And they're gonna say we're gatekeeping knowledge at this point, you have to change the prompt. Why are they writing essays, they should be writing something that's more that involves more thought. You can't just AI something for
this is interesting. And I think going back to like the kind of tool basis of this is, I agree with you that I think that there's this this separation that we're starting to see, that's really kind of fun where computers get to be computers and humans get to be humans, you know, for so long, we've been
trying to be computers. And in speaking to computers and speaking the language of computers, and I think that AI is allowing us to partake in the human experience more by offloading more of that, and we
get better at communicating to commuters, computers at this at this level, right? And I'm excited about that, like, you know, there's so many things that were really hard for me to do and kept me from doing things that I like, like, I love podcasting, I like making videos and all that kind of stuff. But I want
to make those experiences as accessible as possible. And I would spend hours like making sure transcript was right and all that. And now I can give it to Whisper. And it's like in five minutes, like I have a pretty damn good transcript. And it's like that, like that helps me be a better human. But like, I
love that. But we're not there yet. Everything is great. It's aspirational. It's optimistic. And I'm with you. Yeah, that is the goal. Yeah. But then someone's like, Hey, look, I burned down an entire forest to make a video of a hamster in the hamster. He's in his little suit. He's in space. That's
great. How much power did that use? Well, that used enough power to power your iPhone for its entire lifecycle. Like its entire life. That's a lot of power. Text AI is cool, but I don't want to replace artists. Yeah, I will say I have a friend who's a designer. He's a great designer in the space. And he
had a tweet one time that stuck with me where he said, you know, I was so excited for AI to take on all like the menial tasks, and I would get to do all the creative tasks and, and get to make art and do all those fun things. And then turns out, AI is at least how it's starting right now. It's making art,
it's doing music videos, it's like creating the doing the creative tasks. So it has an interesting the way that people talk about the AI assisted art is interesting, because it's talked about as a brush, like something that, you know, you're essentially a task engineer, that's the creative
part of it now. But there's so it's so deep, like, what is the copyright? Like, what, like, how do you get into all this is a whole different topic. We are on this time, spokes, bespoke suits versus like sheen. You know what I mean? Right? Like, yeah, now everyone now everyone who can conceive of something can make a film. It's filmmaking is
hard on purpose. Yeah. 3d effects is hard on purpose. So the question is, is code hard on purpose? And does it need to be? So should any of that be hard on purpose? Well, there's a philosophical question to end on. Thanks for our panel. We appreciate your time. And thanks for everybody for listening. Thanks for coming on. Thank you.
