The Ruby AI Podcast
The Ruby AI Podcast explores the intersection of Ruby programming and artificial intelligence, featuring expert discussions, innovative projects, and practical insights. Join us as we interview industry leaders and developers to uncover how Ruby is shaping the future of AI.
The Ruby AI Podcast
From Rails to AI: How MoMA Powers 200,000 Artworks with Ruby and Human Vision
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Rarely do you get a peek behind the curtain of one of the world's most iconic cultural institutions, but this episode delivers exactly that. Rick Van Michelen, who has spent nearly twelve years at the Museum of Modern Art, joins Valentino Stoll and Joe Leo to unpack how Ruby on Rails quietly powers moma.org and its catalog of over 200,000 artworks.
Because each curatorial department describes art in its own unique way, MoMA requires genuinely bespoke technology solutions, and Rick explains why off-the-shelf platforms simply cannot cut it. (The MoMA Sans font, dating back to the 1930s, has even been incorporated into their AI design tooling.) The conversation moves through MoMA's machine learning partnership with Google, their headless CMS adoption, and the very human challenge of serving audiences ranging from children to PhD researchers.
What does it actually mean when AI makes art, and when is it just "slop"? The group tackles this honestly, pointing to Rafiq Anadol's sophisticated installations as evidence that artistic vision still matters deeply. They also dig into the practical side of AI-assisted development, including managing memory leaks, code review bottlenecks, and a custom terminal tool called Unky Mo.
Tune in for a conversation that is as technically rich as it is genuinely thought-provoking.
Hey everybody, welcome to another episode of the Ruby AI Podcast. I'm one of your hosts today, Valentino Stoll.
SPEAKER_01Yeah, hey, I'm the other host. I'm Joe Leo. I want to start at the top of the show. Valentino, we have crossed 10,000 downloads on the Ruby AI Podcast. Which, yeah, I'm really excited about. 10,000 downloads means I could safely say it's not just my mom and dad downloading this anymore. Like there are some other people that must genuinely like the show. Oh, indeed. With this many downloads, we could start to splurge on things like a laugh track. I really appreciate that. Well, thank you everybody for listening. And we're going to keep recording it. We're going to jump right into it here with our guest, Rick Van Michellen. It's great to have you on the show. I've known Rick a long time, and Rick has a very interesting job that I'd love him to tell us about.
SPEAKER_02Sure. Yeah, I've known Joe, I think we're getting close to 12 years now. And for all of those 12 years, I've been at the Museum of Modern Art, where people probably don't know, but we do mostly run on Ruby on Rails. We made a little adventure somewhere in the middle that we did a bunch of Go, but we're slowly moving everything back onto a full Rails stack.
SPEAKER_01Yeah, and I think you're right about that. First of all, I I'm interested in that little adventure in Go, but I think you're right that people out there, they may not necessarily know the scale of Momo.org just to begin with, and the museum and the internal tools, and the fact that it all runs on Ruby. So can you give us a little bit of overview/slash your journey there?
SPEAKER_02Yeah, people usually think of like museums and shitty websites, probably WordPress. Right. We're not on WordPress. We were okay last week. We're fine. But yeah, so Momo. Mainly because it uh includes all of our whatever it is, 200,000 plus artworks, all of our exhibitions that we've ever put on since 1929, and a bunch of cool machine learning things that's happened on there that we could potentially talk about. Because we've been doing machine learning for MomoDorc since I want to say like 2018, 2019 or something, together with uh with Google. Okay. But yeah, it's a complex beast, and the reason it needs to be this complex and bespoke is because MoMA as a giant old organization just has complex operations. As a leader in your field where each curatorial department has their own way of looking at a piece of art and how you describe a piece of art, it also means that whenever you're talking about a piece of art, it's very bespoke. And so any out-of-the-box thing doesn't really work. I don't know if it would surprise you, but all of the big museums kind of like run their own like bespoke thing. Like the Met also has a bespoke stack, for example, because of artwork is one of the big reasons for it. And then like WordPress is just not or any of those like off-the-shelf CMSs usually are not that great or like historically. And so to like keep it fresh, we just always kind of built our own tools. We've slowly slipped away from that. We're actually like finally using a off-the-shelf CMS, but it's like a headless CMS so that we can still do whatever we want in Rails. And it gives you full control over how you can really create a customer journey. Because we really do have to like start thinking as a big business and like think about what it means to like visit moment.org and who you are as a person. Like, are you on moment at org for just because you're wanting to visit a museum, or are you on moment at org because you're a high school teacher and you're preparing some like art lesson, or are you on moment at org because you're a PhD student and you're doing some deep research into some relatively obscure artist or art form or whatever it might be, right? Right. And we do have to service all of those audiences across the platform. Plus, then there's all of the content that we ourselves generate, because we are also the largest modern art museum in the world. I think that's arguably true. We have to present ourselves to the world and also add to the research that happens around art and or modern and contemporary art, which is just an ever-ongoing thing. Like we did our adventures with NFTs, and we have our adventures with AI generated art. It's um it's part of who we are, and so we can just have an old website. We need to be fresh. I think Momo Dor goes back to the like our first website, I think, was made in like 96, which just speaks to like as a modern art museum, we just have to be with the times.
SPEAKER_00Yeah, before we dive too deep in the operational aspects of MOMA and maybe how it reels and AI fits in. I'm curious, what are your thoughts on Slopcore and like the AI generative movement of art itself? Oh, yeah, let's get into some art before we get into some tech.
SPEAKER_02Sure. I don't know if people actually listen or watch or both. I randomly happen to have like a bus chiat behind me. Obviously, it's not a real busquiat. MOMA doesn't pay me that much. It's sitting on your floor. But it is just sitting there on the floor. Um you can like there's another peak of I think that's a Matisse. Yeah.
SPEAKER_01Can only see the corner of it, yeah.
SPEAKER_02Yeah, yeah. It's that tends to be people at work at MOMA do tend to have a bunch of modern contemporary art that we get prints off. I already forgot the question.
SPEAKER_01Your thoughts on slop core.
SPEAKER_02Oh yeah, I mean it it's bad. And I think for us, I have to speak for myself. I am not an art curator, but the whole thing of modern contemporary art is that it's supposed to be new things. And I have been in meetings where a curator is looking at like something and she literally uses that like stereotypical word of like that's derivative. And that's the whole point of AR art. It's derivative, yeah, right? Like it's not necessarily new. Obviously, there is Ruffie Ganadol who has like really cool installation. It was in our lobby two, three years ago, who now opened his own, I think, museum in LA that's all around AI art. But it's it's a it's a hard line to walk. Like it's not just generate me this thing and it's art. It's not really how it works. You have to be a little more like adventurous and creative with it. So it's not just like cool image gen or video gen. But if you come to the lobby now, we do have I think it's from a German artist in the lobby. We have like a giant screen that is used for some of these like newer art forms. And the last installation on it, not really AI related to the current one, is basically a visualization of what Germany could have looked like in prehistoric times. Like the boglands and whatever. And then they did use because artists are they're like all-round technologists, like people like contemporary artists, right? So it's not like they're good at writing any graphical thing, and so they I think they do use some amount of AI to interpret and help them with their visualizations, and that's maybe that's the right place for it. Time will tell, but I can tell you it's not nana banana. That's not you know considered art.
SPEAKER_00Right. I think AI use in general is like, you know, the whole garbage in, garbage out mentality. I know people that are artistic and they use AI, and their design outcome of AI use is way better than anything I could do. Right? My design abilities are only like subpar. There's something to that. Not that that should be the complete art form, but isn't that kind of what AI does?
SPEAKER_02It takes a novice and makes her like mediocre. Yeah, I'm a pretty bad cook, but like with AI, like it's been great. Like AI recipes that and like instructions, it's been working well for me. Like it's you know, it feeds the family and it's slightly better than what I like, it's and it's a little more creative than me myself, because it's not it's not me.
SPEAKER_01I just used it yesterday to find me a pumpkin seed recipe because my daughter loves pumpkin seeds.
SPEAKER_02For people that are not artists, it's good. For people that are not designers, it's good. Like I love cloth design when I'm doing side projects, it's great. You know, it has the MOMO design language in there, and so like I can like go and have some fun with things. But it's not as good as the actual design that's made by designers. Yeah. And I think the other half holds as well, right? Like I find things that I quote unquote vibe coat and are better than somebody that has absolutely no tech experience. Like they don't really know when the machine is doing something weird. They end up usually with a little bit of a mess. Where like I think as software engineers we have a little more control and can like make the machine do what we kind of want.
SPEAKER_01You took the words right out of my mouth about that. Like, so an artist can use AI and get significantly better art than I ever could because I am no artists, and we may be able to get significantly better code out of our AI because we know how to code. It's interesting to think about, but there's one thing that caught my attention. Did you say that there is the MoMA design language embedded into Claude when you're using Claude?
SPEAKER_02You know, in your Claude design, you can like feed it your Figma files with like here is your like component design system, more or less, right? Sure. Plus, like you make Claude look at Moma.org, and when you think of MOMA as a brand, it's a font face. Like we have our own font, which by the way goes back to I think the 30s. Like it was like written made as like a custom font for the Museum of Modern Art. It's called MoMA Sans. Um and it was digitized in the 90s, late 90s, early thousands, and revisited in like 2019-ish. So like that's our design. It's like black, white, and a font. That's awesome. It does make for like flexible enough that like Clot can work within those like constraints a little bit. But whenever I show it to the designers, they're unhappy. Because it's not good. It's I mean, and they're not wrong, it's not great, but it's good enough if I need to like POC something or like ah, just go with it, you know.
SPEAKER_00Yeah. At least it fits the brand, right?
SPEAKER_02Exactly. Yeah. Right. Like my internal tooling doesn't have to be bootstrip anymore, it can be kind of on brand.
SPEAKER_00I want to circle back to something you said earlier where you have like many audiences you're kind of serving through the site. How do you manage that? Are you literally do you have teams of people focusing on each audience? How does that like drive the decision of the site from a cohesive perspective? Do you find just like needing maybe like a completely different backend or like system to operate specific audiences? You know, how do you keep the sanity?
SPEAKER_02You don't. And it's where I'm director of engineering, we have a really strong director of product that she started relatively recently, but historically we've had very strong directors of product. Because yeah, I don't envy their job because we do have within the museum different parts that try to service these different audiences. The expert audiences, that's where we have curators actually writing some really good material. But we also have an education department that makes content that's a little more accessible, maybe, or and thus scale the gambit from like for kids to for teens to like for adults, etc. And then we have a visitor engagement department that is all about like how can we make the best visitor experience. All of those voices matter, and it is then up to the product direction of like how can we do this without making a complete cacophony of like the voices that might be there. But also sometimes we do end up a little bit with uh design by committee, which is part of being member of a large org with a lot of history. Try to make it as good as we can, and also we kind of know from a journey where people start, right? Like if you're doing research, they usually start from Google and they end up on an art page. If you're planning a visit, they sometimes they also quite often start on Google or now, like some AI, but they end up on like an exhibition page or a like FAQ page or a for kids page, or like those pages are different and like have a different way of like how do you continue the journey from each of those destinations.
SPEAKER_00So I'm curious, you mentioned people using AI to look at the site. Do you find that actually growing? Do you find the need to like start serving those customers more?
SPEAKER_02Totally. We have a whole internal like group of people that are trying to do AI optimization and we work with a third-party vendor trying to figure out how to serve the audiences best. Currently, it's mainly focused on AI optimization for like planning your visit, because we know that that's what people do. Like people just these days like go be like, I'm visiting to New York, I'm visiting New York, what should I do? Any AI really should be saying, like, come to MoMA, that's what we would like, you know? Yeah. And like, here are the good reasons to come to MoMA kind of thing.
SPEAKER_00Right. Can can I buy stuff on MoMA yet with my agent?
SPEAKER_02Uh MoMA Design Store, you can. Tickets you cannot, but the MOMA Design store, like, so because we also have the MOMA Design Store. Right. I don't know if people know, and it's like shameless plug.
SPEAKER_00Um I love the MoMA Design Store. Design the New York Yankees logo.
SPEAKER_02We're a novelty store, really. We're not like a museum gift shop. All the items that we sell have been approved by our you know world-class curator departments. Right. Uh, and so all the items are like design items for the home, which means we sell anything from like TVs to cutlery to like stationery to bathrobes. Like I have bathrobes that I bought you know from the MoMA design store. It's really anything that you just need in daily life that we just decide that like if this is a really cool item and a nice item with a good story, etc., then like it might be worth carrying. We have whatever it is, like what, three, four stores in New York, and a store in Tokyo, and a store in Hong Kong, and uh we have a bookstore in Seoul.
SPEAKER_00How's it work for like an agent? If I'm like, hey, go buy something from MoMA. Where did that journey begin? I am super interested. It's the power of Shopify. Okay.
SPEAKER_02When it comes to e-commerce, that's such a very specific thing. I'm still quite happy that we migrated from whatever it was to Shopify now. Because that's really what they do, right? They're like trying to fight with Amazon and trying to give smaller brands a very like innovative and tech forward way of being able to market yourself and have your website. And so they very early on Shopify had agreements with OpenAI with Google to like implement their standards so that you can just like click a button and it enables you. Or like check out on OpenAI, and like however Google does it and however Anthropic does it. It's just you just enable it and then it does it.
SPEAKER_00I just gave my agent spending power with Link and Stripe. Oh. It was a pretty nice experience. Sounds scary.
unknownI know.
SPEAKER_00Well, you know, it's got a cap. It's got a cap I don't care about, you know. Like $10.
SPEAKER_02But is it like a cap like I have told my agents never to push, and yet once in a while I'm like, huh, you just opened a PR.
SPEAKER_00How did that happen? I use this service called Privacy, which lets me like kind of create gift cards that are then credit cards that are capped.
SPEAKER_02It's like a limited credit card, basically.
SPEAKER_00It's a limited credit card. I have a hard limit that I give it, and then I can like adjust the amount limits based on that. That's right. And Link they offer similar experiences, although like I don't trust that either.
SPEAKER_01What do you have in shopping for?
SPEAKER_00So right now I have the site my bot operates called UPS.dev, which is like uh yeah status page for agents. So if you have a bunch of agents that are running your site, people can like basically see if they're operating or not and like what capacity that they're keeping your site up or not. So if you notice something is off, you could see, oh, it's like their agent is down. I don't know. It's just like something fun I'd use. And so I had another service that I use called now reading.dev, which I use actually a lot, and I had it sign up for an account through UPS.dev and then go through the payment checkout process and then set up its own status page domain. They just did it all themselves, you know. Like they did that brokerage. It was an okay experience. Not perfect, but like I wasn't involved, so like I don't know how much I care.
SPEAKER_02It kind of sounds like a journey that we're trying to attempt, which is at MOMA to sell a membership, it's very complicated. Lots of systems are in play. QA is an absolute pain in the butt, so why not have like agents do automated QA? But that does mean they have to be able to do checkout, and you want to be able to see that that money that was then spent also arrives in the end, like on your general ledger, like thruly, like a full journey of money throughout all the systems kind of thing, right? We're in the very early stages because it is kind of scary. But also there, like we created a credit card that can only be used on MoMA.org, basically. As long as we're the vendor, that credit card can't be used.
SPEAKER_01You could always refund yourself.
SPEAKER_02It's also supposed to do, by the way. Right. But worst case, all I lose is all of the transaction fees. Right. Right. Yeah. Which is still something, but you know. Yeah. That do run up the transaction fees. Yeah. We have a $25,000 membership, if you want.
SPEAKER_00Yeah, I see.
SPEAKER_01You know, that is something that uh surprised me the first time I learned about it, which was that MoMA, and I don't know how many other museums are like this, but MoMA has a a significant membership of people that are pretty much online only. They're annual members, and they may go to the museum once a year, or they may not go at all. They don't live in New York. And I think that is a testament to to MoMa.org and the fact that it's been around for so long and that the aesthetic quality of the site and the experience of the site are very, very high.
SPEAKER_02It's also the brand in general. People do like to support the arts. If we're doing this podcast, say in mid-December, I'd be like, we just released something that's really for those audiences. Oh. Mum's the word for now.
SPEAKER_01All right. No sneak peeks on uh on what that might be. We're only six weeks away from December, middle of December.
SPEAKER_02I feel like there is a marketing plan, and the marketing plan is not announces things on a random podcast. But it will be cool and it will be a first, I think, for the museum world. We're excited and have been hard at work at this this new thing.
SPEAKER_01You had given me a sneak peek of this tool that I was then pleased to see you open sourced. It's called Unky Mo.
SPEAKER_02Oh, yeah, I made that fully available, I think. That's true.
SPEAKER_01Yeah, I'm interested in this. So this is a terminal interface for managing multiple coding agent sessions across projects. Why don't you tell us a little bit about it and your contribution to open source? Sure.
SPEAKER_02I mean, my contribution to open source is really just I have random needs and I will then fix them for myself. Since I spent a bunch of time and tokens on it, I don't care if other people find any of that helpful. Because in the end, you know, we all rely on open source libraries or open source projects that you're like, that was a good idea. Let's try and steal that. Yeah. Anki Mo came from actually another friend of mine, James Summers, who had built something similar but more specific to like the company that he's working at. We're always working on so many different things. At least for me, because like I have, I don't know, uh at least half a dozen repos where like things are moving and I have like ideas that I want to like play with or I'm doing things in. And so you have all of these agents in all of the like my case, it's always cloud code that are in those sessions, and like just opening a terminal tab for each thing, like it just you lose track of what's happening where and when an agent isn't done, etc. So the initial thing was I want a place that's like just in my one terminal window where I can have my coding agent, a little section that shows all of the other coding agents that and what their status is, whether they need input or just running or idling, where you can have like your file tree of the file changes that are happening that you can then browse and like quickly see divs and can open a terminal all within the same thing. Initially this was all built. It's all vibe coded, and I think it's vibe coded in Go. I'm pretty sure it's vibe coded in Go. And the idea is just to like easily and quickly like switch between like all of those different tasks so that you never open VS Code anymore. I still had a key binding to open VS Code. I have since graduated from Unkimo in the terminal, which by the way it was all built on Tmux basically, all like Tmux paints, and it just had its general setup, and the Tmux paints would be like tied together with a bunch of like logic and code in the back end. I now have graduated from that. While it still exists and needs to be running, there is now a web interface for Unkimo, which is even better because I'm in meetings all the time, and I now would because it's a web interface, and as long as I'm running around in the museum, because I'm usually in the museum, it will like send a notification to my phone, I can open it on my phone, and it has all the same things and actually a few more things because you're in a web interface where you can do things that you can't do in terminal.
SPEAKER_01Actually, I was just gonna ask you how that stacks up to the more recent iteration of codex that kind of takes over your terminal. I'm just gonna say up front I have not been enjoying. It did make me think about Unkiemo because I saw yours first, and it sounds like there's an evolution now with the web, but have you tried out any of these other CLI iterations?
SPEAKER_02I tried Codex, but a while ago, I think it's right codex with uh low llama at the time, trying to run things local, which is always a fun experiment. I just don't have the hardware for it. And I'm so tied to Cloud Code now of like how my stuff works and how I integrate with Cloud Code that I'm kind of pigeonholed into it, but also like it's been good enough. Like I've had no reason to spend more time trying to figure out different harnesses or whatever. For me, that's not where I find my pleasure. I have been vibe coding things instead of like playing a video game in the evening, and so it's more about like building random applications that either make my life easier or I'm just curious of how it works and I want to experiment with something. Like that's I think the power of it, as I now can do those things that I never had time for.
SPEAKER_00I've got a very similar setup to Ankimo here.
SPEAKER_02I feel like everybody has like vibe coded like their own version of something like this. My most recent addition to it, which I'm still kind of figuring out, I'm actually excited about, which is purely for the web client, I have an overview tab that takes all of the code changes that are on that branch, compares it to whatever your main, and then tries to visualize it in a bunch of different ways. Because now you'd have all of this vibe coded stuff, and it's very easy that you have like a thousand plus line changes. No way that you're reading that stuff, right? Like not even close anymore. At least when I'm like really doing side project stuff, I'm not reading it. For production, like people should make small PRs and all the good stuff. But we're gonna get to that in a second. Yeah, go on. It's too big, but when things get too big, I still find that cloud sometimes makes weird architectural choices. And then this is my attempt at trying to like see those early rather than finding out later. I'm like, oh, that was kind of weird. So now it's an overview tab and it will take all of the changes and has has like a call graph that gets generated as one of them, which I find very helpful. And like it can, you know, zoom in and out a little bit of like just seeing how like different classes are interacting, kind of thing. And then if you have that within a Rails stack, it's kinda nice because you kind of have like the idea of like how things really should look like. You know, you've got your MV s like your pure MVC stuff, and if there's Too many wires going through it. You're like, something seems like fishy here.
SPEAKER_01You're an engineering leader and you sit across a variety of teams that are both serving public-facing application that is really critical and has millions of views, depending on how you're looking at it, whatever the timeline is, right? You're getting millions of views, millions of people visiting. You also have all of these internal enterprise projects. And you said right before we started recording, you do things like you have your own ticketing system, right? So there's a lot of bespoke technology. The thing that was interesting to me about Unki Mo is that it is tacitly saying, hey, we know you're going to run multiple sessions. We know you're going to start this stuff and generate a lot of code. And so what I'm curious about is what is your position on AI generated code and sort of where do you tolerate bottlenecks versus want people to be efficient or where you want them to be careful? What does that look like on a day-to-day basis?
SPEAKER_02Anything that has to do with like real PII, like personal identifiable information or credit card payment stuff, very careful. Anything that is kind of experimental, doesn't really matter yet, it's fine, vibe code away. But anything that goes into the core stacks, and that's the current struggle as for the team, is trying to like enforce the I don't care if it's AI coded, but you cannot open a thousand plus line PR. Because we still have a human like yes, we do like AI code review, but we still have a human go through it all. Okay. And that's the bottleneck. You know, the bottleneck is how many lines of code can a human properly read without getting cross-eyed and also losing the thread of it.
SPEAKER_01When they're reading the PRs, are they reading for understanding? Are they reading for architecturally? What is it that they're doing?
SPEAKER_02A little bit across the gambit. Like, yes, architecturally, really important. To really understand what an architecture made sense, you have to understand as well what it's trying to do. So you have to read for understanding, which means that's very detailed reading of code, which is why thousand-line changes like or PRs are not great, you know? But it's also for naive solutions. Because we work with mostly contractors that don't have the full history of how everything works. MoMA just happens to be a very complex business. There's a lot of nuance in the different types of memberships and the like perks that you can get depending for different types of like ticketed events and how that data has to flow through for different people and securely. And so there's a lot of nuance there that you might not know of yet if you're relatively new to the team. And so making sure that we don't make short-sight decisions, because like if you give a product like a product person's description of like what the feature is, give that to Cloud Code, it will totally code it. But if you don't prompt it properly with the instructions of like how this should work in the grander scheme of things, because code does flow through multiple repos, multiple servers, multiple projects, however you want to look at it, that's not what Cloud's good at. So you need a human to still like orchestrate that and like prompt properly. And so read for that for bad prompt. It's really like kind of like reading for bad prompting. So one of the things I've been thinking of is should the actual initial and or initial prompts be part of the like PR review suit that somehow become part of it. So you can see like, oh yeah, that was just a bad start of the whole thing. And so like it might not even be worth like spending time reading this.
SPEAKER_01I'm glad you brought that up because I think that is a really interesting thing that some teams are considering. Uh, what do you think that looks like in practice where there's session data or the entire conversation is persisted somewhere alongside the code?
SPEAKER_02I think it's the entire session should exist alongside APR, personally. Because it will allow you to also go back and understand why certain decisions were made if necessary. Because sometimes AIs can go perfectly fine and then like all of a sudden sidetrack them, get fixated on something that really did not matter, kind of thing. Yeah. They try to write really good whatever rescued code, which I don't always need. Because that just adds a bunch of bloat that you know it gets rescued fine in the end, anyways. Like I don't need that extra bloat because it makes it unreadable kind of thing. Having that record, I think, could be nice because it will then allow you to build more tooling on top of it. Because like now, I was saying like I have a few diagrams that get created where I can create based on a set of changes. Now imagine that you could do this, but also include the actual like thought process of the AI, but also what the like sentence structures were and of stuff that people were using. And I think you can again like have interesting visualizations that could be easier ways to like ring some alarm bells of like here's something weird is happening, or this seems all totally fine. To me, it's all about like finding that next tool thing. I think it's gonna be a really cool thing in our industry, is like a lot of people are thinking about like toolifying stuff now again, right? Like the developer experience.
SPEAKER_00Yeah, it makes me think about anthropics like tracing. Yeah, I was thinking of that too. They released a while ago. It would be nice to have a coding version of that to be like, all right, well, these prompts made this shape. That would be some kind of explorer program where you can like investigate how at a granular level the the tokens affected the outputs in real time.
SPEAKER_01Isn't this what Entire was built to do? Well, yeah, CS. Is anybody using that yet? This entire was the the GitHub competitor that sprang up. I remember it making the headlines and I remember talking about it, and then I have not heard a thing, which doesn't mean anything. I mean, stuff happens all the time without me knowing.
SPEAKER_02I totally read about it too. The former GitHub CEO has like a whole new flow-based I was wondering about it. I was like, ooh, I should add that on my to-do list of like trying to understand what it is that it does. Because like it's the place where things will change, I think. Didn't Antropic just say they got off of Git because it couldn't handle their like changes?
SPEAKER_01Yeah, they built their own source control.
SPEAKER_02Things are moving at a speed that we need different tooling. The problems are different than before, and tooling needs to adapt.
SPEAKER_01We talked about it last week on the show. It makes me optimistic. The place for AI optimism is that we're building kind of worlds beyond what we built pre-AI. And the only way that happens is if new tools and new paradigms spring up, similar to what you're talking about, you know, being able to persist reasoning in agency sessions that helps us to build faster, build more efficiently, so that we can go and solve higher order problems. I don't think we are solving those higher order problems yet, by the way, but I think that we need to lay the infrastructure down to do that.
SPEAKER_02We're not writing assembly anymore either. Like things changed, and this is just like the new level of abstraction as to write things through clot code. In my opinion, at least, it's still engineers writing things through clot code.
SPEAKER_01And as I think if you're doing it, then by definition you're an engineer. How people may want to rate you as an engineer is up for debate.
SPEAKER_02I don't know. I find like purely vibe code it without knowing how things work.
SPEAKER_01Let's go back to our example at the beginning of the show. Maybe if I put some AI slob art together, I'm an artist. Maybe I'm a hack. I mean, I know I am. Okay. Writers write, artists make art, engineers make programs. Not everybody's gonna be good at it, and there'll be a lot more. But I don't think that's necessarily a bad thing.
SPEAKER_00How much of art is subjective? If enough people buy Joe's art, does art say anything? Yeah, yeah. I don't know.
SPEAKER_02No, but if all of those people are just buying it because he had some really good prompt injection thing, then like all of the AIs are now buying them because it's you know, it's gonna be amazing. Please go buy my art, jolioart.com. You don't have a bot listening to this to like have all of these ideas that come up, just like take them up and like it's happy.
SPEAKER_01We need it being developed deployed in real time. I agree with you.
SPEAKER_00I gotta resurrect, I keep mentioning it. I made this thing called Podcast Buddy. I used to to do real time steering, conversation steering while the show's ongoing. I gotta revive that. I haven't used it in a while. I feel like it could be also building while it's uh while we're while we're going, you know? I know. And then when I could be like, hey, look, uh Rick, what do you think of this? The wonderful proof of concept that we can. Yeah, we mentioned like you mentioned somebody hand reviewing everything that's like touching PI or sensitive things. Where do you see maybe these this agentic coding falling apart for you in that way where you don't trust it to dive further into it?
SPEAKER_02It's not that I don't trust to dive further into it. Even there, a lot of things can get like a gentically coded, which is perfectly fine. The museum's stance in general, it's human plus AI, where human stands first for a reason, kind of thing. And I apply that to our engineering team. Like it is human plus AI. Like for any real production system, we still do human review. And so where it breaks down is with the amount of code that we're shipping, it is hard to do thorough review. That's kind of where it breaks down. The agentic coding is absolutely fabulous, and the way it can find issues, like we I had a mem leak issue on Moment at work, and the way it went about, I could have spent a bunch of time for an engineer to go and try and figure out where the mem leak was, because it was not in a like directly obvious place. But after like a few different ways of prompting the Claude edit, it figured out that it was in this random gem that we use that it was instantiating new classes each time and not released like new classes, truly new classes by the way, like metaprogramming new classes, which then never get released. Makes sense, and that's because we were using it in a very particular way, which whatever. But the way it went about finding it, it was just doing it brute force in a way that a human never could. It was like, I'm gonna like go through all of the pages and load like all of these big pages hundreds of times and see where the most memory allocations happen that never fall off. I could never do that by hand. I mean I could, but like I'd spent way more time on it. And here I was like, oh yeah, yeah, I did this 5,000 times and like it was clearly here. I'm like, okay, cool. Fix it. You know, you suggest me to fix. It's a 20-line fix, you fix it, and it can do the exact same test, and it's like, yep, that fixed it. And also I can still compare pages before and after, and everything seems fine. The only thing that dropped was memory allocations, and you're like, that's what it's good at. Let it do those things. It's not that I can't touch it there. Like people totally can put AI code in even sensitive parts. It just has to go through human review. And that also means when I'm working on a production system, I don't do big tickets, you know, like you don't ship thousands of lines. You still have to break it up, and that means you just have to slow down still for your product development. Because we can't keep up.
SPEAKER_00From the perspective of Rails, how do you weigh like agents' ability to kind of handle maybe more mature Rails code bases versus green field ones? Where do they stumble on Rails conventions? Have you noticed any patterns?
SPEAKER_02Yeah, they really do struggle with giant repos, and I tend to have giant monorepos. I never liked the microservices infrastructure thing. There is a place for it and we have some, but when you point it in like a giant thing, it still struggles with it. Even with a big token window, it deems it not necessary to understand the like whole thing. And AIs are just really bad at generalizing. When we look at a big repo, we can generalize of like, oh yeah, that lives there, this lives there, this lives there, and generally have an idea of what kind of happens everywhere. Even with a good Claude MD files and other and rules in place, like it just doesn't understand that. Like it still will forget and not keep those things into account. That's where it breaks down. While with Greenfield, it's fully building it up on its own and it organizes code potentially slightly differently.
SPEAKER_00Does that make you think maybe smaller services?
SPEAKER_02No, I just think it's a matter of time. These agents get better. Like I don't think it's worth ripping things apart to then in a year from now have them be capable anyways. Like then it was a waste of time. So like it's fine. It just means you have to do good prompting. That's where you like there's a job for the engineer, and that's the good prompting and the steering it of like make these changes here, make those changes there. I would solve it this way. What do you think? You know, like have a better conversation with it rather than just here is a ticket, go do it.
SPEAKER_01Well, that's what I was gonna ask you is uh does every new session that gets started and pointed at one of the large mono repos, does it all have to kind of start from scratch and learning, or are there pieces in place that are guides that help, whether it's a a graph, whether it's different skills, is there ways that you can kind of point them in the right direction in the meantime?
SPEAKER_02Yeah, and that's the usual tricks of your good README files and Claude MD files and subfolders and have like a nice description of like your main one of like this is kind of what lives here, like good description stuff. I don't find graphs helpful to feed it yet, because these LMs are just better at textual things, like you just have good descriptions of what lives everywhere. But even with all that, I feel in big repos it doesn't do that great of a job. What I found personally is that when you let an AI take care of it, it breaks things out even more rather than your pure MVC things. They like to think of services. I don't know if that's maybe just a thing that we didn't use as much historically. They really like creating modules that you then include for things, and they seem to be better at maintaining it's kind of more smaller sets of code. It's kind of like your microservices, you now like wrap them in little things, and that's how they approach us when you green fill things. Well, if you didn't do that from the get-go, it struggles a little bit more. It still gets there just fine.
SPEAKER_01We've got just a few minutes left. This popped up in our research, and I'm curious if you want to just chat about it for a minute or two. Do you remember being a part of the MoMA hackathon with NYU, School of Continuing Professional Studies?
SPEAKER_03Yeah.
SPEAKER_01It was just a cool story. I saw that it looked like 43 different students participated and came up with different AI-powered tools. I saw like a Wayfinder, a personalized guide, and visitor experiences. What was that like being a part of that?
SPEAKER_02It's really fun. In general, we were now doing four or five-ish hackathons a year. Oh, okay. I think that was our first one. Then there was an internal one together with Google. And now we just had one that was together with Adobe engineers. So like Adobe gave us engineers, we gave people a few like separate departments, and so we're trying to like have interesting combinations of like the education department, for example, with visitor engagement and some of the curatorial things together with like a bunch of Adobe engineers, which was really interesting. And we'll try something around purely around games, and we'll do some of the curators that are curatorial assistants that are in that realm together with some engineers, maybe, and we always try to partner with like a Google Anthropica, whatever it might be. They're really interesting. I think has been the most interesting if the prompts are similar enough for the hackathon of like what we're trying to achieve. The solutions also are quite similar, and they're all usually things that we've considered or thought of. Wayfinding we know is a problem in our building, which is why we keep asking that question. But all the solutions are still like there's still things we can do. Like you cannot do a blue dot in a building that has 60 stories above it, but we're also very vertical. So we, you know, like Mooma is six stories, is about the like size of a New York block with a bunch of concrete around you. You cannot rely on GPS, you cannot rely on beacons because of like ceiling heights and stuff, and beacons are you need like a boatload of beacons, which is like an operational nightmare that you can't do either. So like a blue dot is like the holy grail that everybody kind of wants, but we can't figure out. I'm waiting on you know, Apple, Google, etc., to fix that problem indoor navigation.
SPEAKER_01It's interesting that you're having all of these hackathons, but the ones with the students, it intrigued me because I'm just curious to know what are the kids thinking? What are they doing with AI? Are they looking at it as an existential threat or are they looking at it as a very cool opportunity and a tool?
SPEAKER_02I think the students we had were looking at it as a very cool opportunity and tool. I think they approached it because also the the NYU or our partners were really good and finding the right set of students across all of NYU. So this was open to students from like any program, and they all kind of like embrace the whole we'll try to come up with ideas and then use the human plus AI approach to build proof of concepts in literally a day, right? Like they start at nine and they present at four. Hackathons back in the day usually used to take a weekend or something because you needed way more time to build something. Now you can do like it can be your lunch hour. Yeah, yeah, exact exactly. To me, it did seem like the students were very happy to embrace it for execution of things, which is exactly where it belongs, you know. Like it's a tool to help us all try a bunch of new things. One of the like interesting ones are always about how do you tie your on-site visit and like take that away with you? Like, what is the before and after to make it an ongoing relationship with MoMA? Because we do have like three million people that come through our doors every year. How do we keep a relationship going with them for the next few years until maybe it's a decade from now that they can afford their next trip to New York? But we can still build the relationship and like interesting ideas. We're always open to it.
SPEAKER_01Rick, as one of those three million people that goes through the doors every day. Thank you for all the work that you've done, and thank you for your ingenuity and your leadership across all these tech teams, and thanks for sticking with Ruby. Keeps us all working, especially here at the Ruby AI podcast.
SPEAKER_02Ruby really is awesome. It makes that human plus AI thing so much better. At least we can still read this thing. It's like a very human readable language. Thank you for having me. Uh, it was an absolute pleasure. All right.
SPEAKER_01Yeah, thanks for coming on, Rick. Thank you. Thanks, everybody. Talk to you soon.
People on this episode
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
