Sign in or Join the community to continue

Why Stripe Cut 500,000 Internal Docs Down to 5,000?

Posted Nov 13, 2026 | Views 3

Share

Speakers

Dave Nunez

Co-founder & CEO @ Falconer

Dave spent nearly ten years building knowledge infrastructure during hypergrowth at Stripe and Uber. Dave leveraged the power of documentation and developer experience to build Stripe's legendary product-led growth engine. He co-authored Docs for Developers and advised teams at Anthropic, Graphite, and Apollo GraphQL on developer experience and documentation.

+ Read More

Demetrios Brinkmann

Chief Happiness Engineer @ MLOps Community

At the moment Demetrios is immersing himself in Machine Learning by interviewing experts from around the world in the weekly MLOps.community meetups. Demetrios is constantly learning and engaging in new activities to get uncomfortable and learn from his mistakes. He tries to bring creativity into every aspect of his life, whether that be analyzing the best paths forward, overcoming obstacles, or building lego houses with his daughter.

+ Read More

SUMMARY

What happens when AI agents start relying on the same messy docs your team already struggles to search?

Demetrios hops into a Waymo in San Francisco with Dave Nuñez, founder and CEO of Falconer and co-author of Documentation for Developers. They talk about why developers and agents need different things from docs, why agents sometimes skip up-to-date instructions, and how a stale internal document can contribute to a production incident.

Dave shares how Stripe cut roughly 500,000 internal docs down to 5,000 worth maintaining. The conversation also covers how to capture the reasoning behind engineering decisions, when a diagram beats a wall of text, and who owns the fallout when an agent acts on bad information.

+ Read More

CONTENT & TRANSCRIPT

What's up folks? I'm Demetrios. We made it to sunny San Francisco and whenever I'm here I enjoy chatting with my friends who are working on AI agents because they are seeing what is at the forefront of this whole industry So let's go hop in a Waymo and have a conversation What's up here? Alright, I'm here with Dave. We're doing podcast in a Waymo. Waymo Cast. You're the CEO and founder of Falconer? Yes. And last time we talked, when you were on the podcast, it was all about Yeah. documentation and writing for developers. And I remember in that specific conversation, I asked you what your feeling is on documentation now, because it feels like you have to put a lot of onorist on the person that's writing the documentation. But these days, dude, and by the way, you literally wrote the book on documentation. The literal book, Documentation for Developers, you wrote. And so it's like, where we at now because documentation has changed so much since three years ago when we chatted. Yeah. And I think at the very end of that conversation, you asked me like what I'm excited about or something. I'm like, actually, as much as I talked about external documentation, I'm more excited about internal documentation. And that was just like a weird kink. Like, why would you want internal docs like for your teammates, you know, dozens of teammates, hundreds of thousands, when you can have millions of stripe developers. And that ended up being like a very lucky weird thing to be into because that's what powers agents. I have a lot of feelings like it was a roller coaster at first because it's like, wow, it took me used to take me two weeks to write a change log for a release, and now I can do that in 30 seconds. Like what is gonna happen to my craft? Yeah. And then I realized, well, I always hated writing the change logs. So please. Why are you holding it to you? Yeah, generate those. And then it became very clear that every like documentation I think is worse than it ever has been. And like we're we're guilty of this kind of on purpose because we've been asking ourselves the past couple years, and I've been talking to friends at the big labs that care, like documentation has to change. Yeah. No, and we don't know how, we don't know why. Or I mean we don't know like how to do it. But like agents need very different content than humans. And I think what everybody's doing is like, oh, I used to write bad documentation before, now I can have have agents write bad documentation for me. And so you go to a random site and it's just like walls of text, it's just slop, it doesn't help you. So it doesn't help the agents, and it doesn't help the human. So I'm like more fired up than ever to like there's more opportunity now that because we're pushing out so much more documentation. Yeah, yeah, and people justifiably don't have to read it as much. So if they do read it, like who cares if it's 99% agent traffic? If If I'm going there as a human, it is extremely important. I need something that the agent couldn't get me, I need to visualize something. Yeah, so it's more important than ever that if it is a human, like you're expecting them to put their own time into actually going and looking at it. It better be good. Yeah, it's it's the delivery method. Like if I'm an agent, I just want markdown. I'm gonna read every single character on the page. Just give me markdown, give me endless amounts of markdown. All the context, it doesn't matter, just give it it to me. If I'm a human, I don't want to read markdown. I don't want to read it all. So like don't even give me text. Like read my mind, show it to me in a format that I like. Some visuals. Yeah and give the give the markdown to the clankers. I don't want to see that. But right now it's all meshed together and people just conflate it like oh, agents and humans need the same thing. It's just like the opposite is true. Like just slough it off to my agents that are gonna be doing the actual implementation. Like I want it, I want the big picture. I have different needs than my than my agents. It's funny because I up until now have been saying that oh well, you know, you can write documentation That humans can read, but agents can't, but you can't do it the other way around, where agents can read it and humans can't. But it's almost like, oh, now seeing your point, it is true that just because I can read it doesn't mean I want to. And if it's not optimized for the human, it's going to be 10 times harder for me to actually sit there and read it. Yeah, we have multiple senses. And so the cool thing is like as we make video, as we make graphics, like agents can read that too. But agents don't have the feeling of, oh shit, my boss wants me to do something, or I need to like implement billing before we ship tomorrow. And that feeling of dread when you can't find a crisp answer. Do you support this form of off? Do you support this currency, yes or no? And you're like, okay, this must be a simple like thing I can verify, and that feeling of dread when you land on the docks and they're terrible. And it's like a wall of text. Like agents don't have that feeling they'll find the needle in the haystack if it exists. Yeah. But if you're human, you know, you have that feeling of dread and now you have that bad impression of this company um versus turning that into a positive experience of like, hey, come on in. This is it's it's almost functioning like a marketing site. Like hey, come on. Especially for developers. Right, exactly. We've put we put time into this, you can do this with your eyes closed, come back the next time, tell all your friends. Yeah. So like really that like human part of it is more important than ever, and that's what people I think are the worst at because it's the hardest thing to do, ironically. And there's another way that I've seen the ability for agents to grasp what your product does, or how to use your product, it's not so clear like how we write documentation for agents. You can just put everything in there, but then I've seen a company that does like evals on how well agents can use different tools. Mm-hmm. I think they're 2027.dev. They're doing super cool stuff because they're saying, look, the common tools out there, the Vercells, the Tail Scale, the whatever it may be. I'm giving my agent a lot of different tasks that need to use these tools, let's see how well the agent can use it. And some tools the agent uses really, really easily. And we don't really know why other tools it doesn't. And I'm sure there's a lot of like, well, maybe it's because there's great documentation, and maybe it's because that tool has just been around and there's more of that code out there in the world. Or maybe that's like a minus. Who knows? But what what I'm trying to say is it's not clear why. Why does it work so well on some tools and then not so well on others. Yes. Oh that's so good. And this this reminds me why this is like a very, very hard problem to solve. Like the old way it was it was a hard problem and we took the time to solve it at Stripe when it was just humans, because it's information architecture, it's search, it's writing quality, it's layout, like it's a it's design, it's authoring experience. Like now it's very, very hard in a different way, but like what you're describing, how do the agents even read what you're what you're writing in the first place? place. So like the legibility. And then there's these very interesting like mini research like people have done like the the head of um for she's she's high up at Stripe Michelle Boo. She talked about like agents ignoring their instructions like in the docs and like how do you like prompt inject the agents to follow what's in in on the page and ignore their training data. Because agents for the sake of speed they they cannot travel faster than the speed of light so they have to lean on their biases. What do I already know about Stripe? And I can just like ignore, like I'm already making these assumptions and givens. And so they're using outdated data, they think they don't have to fetch the latest thing on this page and like an example for Vercelle is all of a sudden they had this big Docker launch and like the agents were still recommending competitors because they they were uh leaning on their training data or already know this thing. So I'm gonna give the the the um question ask the person that's asking me like does Vercelle run on Docker um Uh an answer that is wrong because I think I already know it. And meanwhile, you want it to go crawl all the thousands of Vercell's latest pages to give you the right answer. So it's it's a really, really interesting problem to solve. Like how do you make it legible, and how do you get them to follow instructions properly? Yeah, the most up to date information. Because sure, they can search, but if they think they already know it, then they're going to lean on, oh well, yeah, I already know this. I'm not going to search. Yeah. You have to make a trade off where do you want speed? If you want speed, the agent's gonna make assumptions, lean on his training data, it's it's it's uh inherent biases, And everybody is shipping 10x more, writing 10x more. So think about in two, three years from now, like it doesn't matter how fast the agents are, they're not gonna be faster than speed of light. Are they gonna read through your 100,000 docs and quick starts like every time they get a question? No, they're gonna lean on what they already know. So it's it's a it's a very hard problem to solve that you just cannot lean on today's or or yesterday's practices, which I think everybody is right now. Wow, yeah, because the problem is only going to get exponentially greater. So much, So much, yeah. We did talk about internal docs too the last time that we chatted. I have since kind of gone down a rabbit hole on the whole idea of like creating a decision dock. And so Love. if there are things that are done at your company, you have this decision dock on why it was done like that, who decided it, what the rationale was behind it, and so you can see that trail. It still feels like you're going to want to like the value of that has never been greater because then an agent can see it and it won't try and do it a different way, right? Absolutely, and not even an agent, but you want to see adults throw tantrations at work, it's repeating themselves or somebody not remembering the decision they made, or somebody like we have this, we have this feature for our agent, remember this. And I was just arguing about it for our lunch cuisine today. I wasn't gonna make lunch, and I'm like, Falconer, remember what my cuisine is, tell the team. it's been used against me multiple times. Like when I remember one time I was like, you know, said some offhand combat uh comment about a company, I was like, nah, we would never use that. Like that's the antithesis of our philosophy. And later on, they were becoming a prospect and a lead, and I'm like, guys, this customer, this company's so freaking cool, like we should do a case study. And somebody on my team was like, You said you never wanted to be associated with this brand. I was like, I would never say that. Oh man. And she's like, at Falcon, what did Dave say? And it was like, I never want to be associated with this. And I'm like, you just like you forget your own decisions, let alone what your team makes, let alone like all the little offhand things you want your agent to use as checkpoints. So that is a like, I think we're just at the beginning of like logging decisions, but yes, like that is the ultimate. Well, and when somebody wants to onboard and they say, Why do we do it this way? What is the reason and rationale behind that, and you can see that decision and say, you see that we used to do it this way, then someone proposed this, and ultimately we went with that because the pros are this and the the cons were this. Exactly. But then when you see that whole transformation, if something has changed, you can know maybe it's time to re update this decision too. Absolutely. And that happens all the time. Smart people come in and frontier models do this too. Like you want it to fix one bug and it tries to refactor your whole code base because you made all the and it's like no, don't touch it, it's there for a reason. and you know, an engineer comes in and is like, Why are we using Mongo? We need to rewrite all this in MySQL, and somebody's like, Here are the many arguments we've had over the years, and then it, you know, it starts to make sense. But yeah, absolutely. Or it can be well, yes, MySQL has since changed these things, so it's worth us re-evaluating. This one tiny thing that this vendor doesn't do that makes it a showstopper for us, yeah. And um, and it's really easy forget those, and it's really easy to argue about those, and it's just not in code, like it's in people's heads. Yeah. Which is another thing that makes it so hard because you go, you say things, and in Slack, it usually plays out in Slack, you're having this conversation. It's like, well, why are we doing it that way? Oh, because of this, this, and this, and you have this whole thread, and you're like, but that actually doesn't matter anymore, does it? And so there's people that are having to chime in, spend their time, and that potentially is not the most valuable use of their time, right? Trying to defend decisions that were made in the past. What are other internal documentation things that you've been really enjoying? I think I mean the decisions are incredible because we just we log things and you just need a timestamp. It's funny how people just run in front of Waymo's because they know the Waymo will start. It has to stop. Yeah. You get like cut off because this is like the nicest driver around. So the cars just go around, people run in front, they know it's safe. They don't care. Yeah, stop sign. Yeah it's my right of way always. You're not gonna get flipped off by the Waymo. I think before we get to the cool shit, like decision records are incredible, and I love, and I'm telling everybody, just write stuff down with a timestamp. You don't need to perfect it or or make it like beautiful. You can do that later. If you just you can if you write it down and keep it in chronological order, like you can do stuff with that later. I'm not even I I think internally people just have to clean up their junk. They don't realize that 95 probably, and and this is This has proved out true from doing this exercise at Uber and Stripe, and then a bunch of clients that I was advising. Probably like one to two percent of the stuff you have is actually useful. Ninety-eight, ninety-five percent, let's be generous, is copies of docs, outdated docs for deprecated features. It's stubs, like just scratch pads. And all of these are Google Docs, they're Notion Docs. Like whether people still read them, they're in the In the context for the agents, and they're in your search. So when you go search, and they're booting it. And then a lot of these search tools provide weight for age. So the older it is, the more I remember we're working with this customer that had uh like 8,000 employees. And the first thing I do when I search, they were using Notion to like test how good their search is. I'm like, I'm new to this company, I'm a new engineer, how do I get started? And the top hit was titled Jason's Intern Onboarding Dock. Do not use this, but please read. And then you click in that, and it's like this is the top hit because I was the first person to write an onboarding guide. Oh no. But this is the true dock. Like, click this one, this is the real Ombre dock, and of course you click that and it's a dead link. But like it's just like people just are like, Well, what are you gonna do? You know, search is search. And I I just refuse to take that as an answer. Get rid of all of the junk, reconcile it, and now you start the and the cool thing with agents is once you have this baseline, like Stripe we took 500,000 docs, got them down to like 5,000 we actually cared about. Wow. Now, like at the time we had people, you know, keeping things up to date and it was it was terrible, um, impossible. Now you can you get it down to those 5,000 docs, that's like very doable for an agent to like keep that in sync with the code base with tasks. It's not gonna be perfect, but you're you're gonna be like 90% of the way there. Dude, and I can't tell you how many docs I don't delete because I'm like, there's probably one sentence in there that's actually valuable. Yeah. And I know that it's not important, but that one sentence potentially could have value in the future, so that I am too scared to delete it. Yeah, everybody has that. Yeah. And you remember, oh that took me so long to create. Like I don't want to. It's like cleaning out your garage, but it feels so, so good to delete stuff. Cause right when you delete it, you never think about it again. You know, like and if it was important, who knows? You won't you won't know. Well, even when I do think about it, because of that search problem, I can't find it. So I'm sitting there. I'm like, oh, didn't I create something like this before? And so I go searching for it, and then I can't find it, and it's so frustrating because I know I've made it. Yeah. I just don't know where it is. Yeah, and and other cool stuff too, like people internally love a good flow chart or a diagram. Don't give me a 10-page software development lifecycle doc that was written by an engineer that's no longer here, and people give it to me and they're like, this is mostly out of date, but it's directionally good. Like give this a read. Like, ah FML. Give me a diagram that shows the major pieces, and you can accomplish so much with just like the width of the page showing me, okay, we start here with a PRD, and then that moves to a prototype, and then that gets spec'd out, and then like that alone is so much more useful. So that's that's probably to answer your question, like I would say look at the stuff that can just be distilled down to a a diagram, a workflow, a checklist, and like get rid of all the old context. Just delete it. Say that, it makes me think about bringing up the things in the moment and how with the way we work, that's one type of doing it. Type of way of doing it. But then you've also got like looking at the code base and how is the code base actually built. But when you get to a certain scale, I'm sure that the code base also is another thing that it is massive amounts of code and repos and everything that you now have this context blow problem on that side, too. So not only do you have the Notion Docs or the Google Docs that give you English, but then you've got code that goes with it. And if the majority of the stuff doesn't match or it just is overwhelming to the agent, you're really rolling the dice on if you're gonna get anything valuable back from the query that you've asked. Yeah, absolutely. And and code is is pretty pristine. That's what the agents were trained on, so what they're optimized for. And if you have dead code, delete it, but agents are gonna know how to traverse that and what to get out of it. But yeah, you're right. They start to get confused when they're taking okay, this is the code base, but your name is tied to this documents conflicting with what's in the code, and it's conflicting in this old Jira or linear task. So like I'm just gonna flip a coin. Because I'm meant to please you, and your name is on the code, and your name is on the task, and your name's on the dock. So I'm just gonna make a call here, and and it's so great because I'm like a magnet for friends at companies where they're like, like I just heard the other day, somebody was like, We had the worst incident I've ever experienced in my career. It was weeks of cleanup because an agent made the wrong call based on a a document. Like it is this happened to me at Uber, except it was humans not updating the documents. Like agents are gonna do the same thing, but worse because they're they're gonna write something down and they're gonna make it seem and you're gonna trust it because you're gonna think like, well, it's it's here. Um I don't have to go ask the person who actually owns it because something is written down by by Claude, so I'm gonna trust it. It's more dangerous. Dude, that just makes me think about the people or the ones who have to actually clean up the mess once it happens, because this is almost like a latent problem until it's not. And then you get some kind of an incident, and somebody can't figure out what the hell is happening because the documentation's been a mess for ages. Yeah. And or the agent is trying to figure it out and it's making mistakes because of documentation. And so you almost don't realize how bad it is until something goes wrong. Yeah. And we have been in a in in a period of the last couple of years where you're allowed to blame Claude, you're allowed to blame the agents if something goes wrong. But as per f a few performance review cycles come around, people realize like, oh, I own reliability and my team's docs uh went down, or some other team's docs caused it that were written by Claude, but I own reliability, I'm getting dinged in performance reviews. All of a sudden they're gonna start to care. Things aren't gonna be as like uh as laisse faire and yellow as before of just like trading, you know, blindly trading what Claude says, blindly publishing it, because now you're responsible. So that's the when when people ask me about docs, like what tool should we use? What should we do a style guide? I'm like, start with accountability, because if you if you put a name to a doc set, and just like a code base or a repo, people will figure it out how to care. And the next step of that is during performance reviews, like put it on the job ladder. Like, are you responsible for the documentation? People will figure it out, it will all cascade, like like smart people will figure it out. And I think that's just kind of been blown up the last couple years. But I already see it changing, like ownership, accountability, people know how to measure performance when you're pairing with agents. And so I am optimistic that like you'll start to see that like, oh shit, you cause an incident, somebody else's team wrote the docs, but it's your responsibility, it's your metric that you own, like that's on you. Yeah. Well, and that whereas before when if or when Clause Claude or Astra or whatever it may be, Codex causes the incident, it's kind of like, oh, because I was testing the limits of the coding agent. And now that's not an excuse. Like you have to still be an engineer and you have to be the owner of whatever is happening, like you're saying, like you have to own reliability. And so if that means that you can do it moving fast with 50 million coding agents, cool, go for it, because you're able to architect your software factory in a way that you know it's gonna be all right. But if you can't, like you can't use that as an excuse, now my dog ate my homework. I'm gonna No, do it. Yeah, exactly. Especially if you're if you're B2B, like no like the the there are contracts at stake. There's compliance audits, there's like hard stuff at stake where it's not like you know the customers gonna be like, ah yeah, got us to. Uh No, you have to figure out a way to paper over GitHub if it's going down. Like if US, it used to be okay if US East went down because everybody went down, and it's like, well, you kinda have to figure out a way to be highly available no matter what. Like your customers don't give a shit if it was Amazon's fault. Use it as an excuse. So I I'm starting to see responsibility, accountability um uh come back, which is which is a good sign, I think, for everybody. What are some other tricks or ways that you've seen it done well that you've said put names to the accountability, just have a document that says who owns what, and that will figure itself out. Another one is put owners on documentation. Are there other things that you've seen to work well? You have to treat documentation as part of the product. Like that one is evergreen. If the product is ready and you ship it and it's not documented, then you don't care about docs. You might as well not even do them, because like who cares? And internally you have to treat it the same way. Like there is this amazing, it's like the the the holy scripture of documentation people that Jeff Bezos had written some memo. I don't know how to pronounce the name. Who's the gas town guy? Steve Steve Yeege. Yeah. He's the one that actually talked about it, and it's so funny. It's written in like a read me in a GitHub repo buried somewhere. But at one point, Bezos was like every like communication is a defect. If people are talking to each other, that means that you don't have properly designed interfaces that are well documented because you should communicate through interfaces and and well documented APIs not through meetings. And I love that because it's like the introvert's manifesto of like don't talk to me. I don't want to talk to you. Like document your stuff and then we'll socialize over lunch, but I don't want to socialize or you know have to stop what I'm doing to explain how this this endpoint works or or how to get going. And um and so that is I I think that was like the the early microservices type of philosophy, but I think that still is actually more important than ever. Your team should be an interface to the rest of the company. So how do you, what's your operating model, what are the tools you use? If you do have internal services or infra, like how do I connect my tools to it? Because the cool thing is now it's like agents can do more human like things, so they want to know what your working hours are, what your communication preferences are, what your roles or responsibilities are, because they can do so much with that information. Like, don't schedule a meeting to talk about stuff that could be written down. Yeah. Yeah, so you talk to so many people across the space, like, and I'm sure you have opinions and they have opinions on the future of documentation. Like what it what what's the opinion you've you've formed recently? So when it comes to dude, underappreciated asset, is what I say. I like that. Yeah, yeah. Doc should be an asset, right? And that's why I love talking to you because you are so deep in this practice and this craft that you understand all the ways that we can make it an asset rather than a liability. And I think the first time that we chatted, I quote this all the time to folks, how you would think about little micro almost philosoph philosophical things or psycholog psychological things that the people that are reading the documentation would have to go through, and that was with the escape hatches. And so what you said was that you would always in any documentation that you wrote have a few paragraphs in. Is this what you were looking for? Or was it something along the lines of this, which is similar, almost like a recommender system of docs that you could have meant when you were looking for this, so that somebody could traverse easily and not have to read through the whole documentation. That is what I look at as a document being an asset because I am not wasting my time when I am looking through the docs. And the fact that it's so easy to churn out so much slop, we all are getting sick of reading slop. And I now have come to a point where I say to people, if it takes me longer to read your document than it took you to write it, I'm not gonna read it. I call that a bro, like a novella. If it took longer to read read than it took you to generate, like you're just you you're you're forcing your lack of rigor on me. Exactly. And it does, like if you go to any random this is why I'm so angry and fired up about like docs today, because you go to any renowned company's dock site, it is that slop fluff. And it feels like I'm getting the Yankee candle. You know you walk into like a bed bath and beyond just like ooh somebody's baking cookies. Shit, that's that's just like the cookie Yankee tricked me, yeah. And and yeah, like it you get repulsed after a while. That's what I feel disrespected. Somebody just disrespected my time so hard that they look through and they think that I'm gonna sit spend my time, which is the only thing I can't get back. Absolutely. It's the most precious thing on in our lives. And now I'm I have to sit there reading some slot that you generated. Yeah. That for me is why I feel like it is an underappreciated asset, because as of now, it's okay to do that. Like the norms haven't changed, but I get the feeling that enough of us are gonna read enough crap that it's going to start really dinging your reputation in ways that you don't want. And so the next order effect of that is going to be that you're not going to put it out there. Or you're at least gonna edit it before you generate it. Yeah, yeah, that's a good way to put it. Like the rigor is missing. Like you can get the initial output from an agent, but the human rigor. Because you can you can empathize with the and reader. So like what would you want to read? I want to feel smart. I want to feel uh accomplished. I want to feel like a moron, you know, reading your instructions because I don't understand it. Exactly. Well, dude, this has been great, man. I appreciate you coming in here and talking docs with me. Yeah, anytime. Are you coming to can you come to AgentCon? I be I was if this was Friday, but now that it's Monday, I have to go home. Oh, Yeah. because you're based on a Santa Claus. I'm in Santa Barbara. That's right. Yeah. So I sparked half my week up here. Where is it like an hour or away, right? It's close to San Jose, though, right? 400 miles south. Oh 400 miles. It's 100 miles north of LA. Oh, Santa Barbara's closer to LA? Yeah. Oh, I'm thinking of Santa Clara. That's right. Yeah, like ah Santa Claire's close, right? No, Santa Barbara. Santa Barbara, yeah. So I I fly up um every week. Well all the more why this is so cool that you did this and we made it happen. Yeah, this is fun. How many of these are you have you done are you doing? I have one more. Well yeah, I just did one with uh Jesse who created superpowers. Do you know that? Speaking of writing and all that fun stuff. Sounds familiar. The superpower skill pack. Super cool. Yeah. I saw you you talked to Zach, which was cool. He's one of our angels. Oh yeah. Yeah. Oh nice. He's dude, his stuff was really good. It's a while back now, but yeah, it was very cool. And he's a good writer. Yeah. Oh yeah. He he takes it seriously. He writes a lot about software factories, which is cool. Yeah. Yeah. Yeah, and really nice. And then we have our our big GA launch on Wednesday. So Ooh. that's huge. Tell me when it goes out so I can, you know, review or like comment. Yeah, that would be that would be huge. Very cool. Yeah, and we'll I'll send you this um like this recording. Hopefully in Give me like two weeks, potentially three, uh for it to go out, you know, but if you want it so that you can make like you know shorts and all that fun stuff. Oh amazing. Yeah. That'll be killer. Oh I'm I'm remembering now you you uh posted about my Neuralink content. The sad part is I actually believe it. I was like I had to think was what could disrupt What could disrupt me? Neuralink shit. Oh wait, but now No, there's too much noise. Talk about context. Yeah, like context blow. And we really gotta get better. 'Cause Oh man. Just like meditating when I'm trying not to think. All I'm doing is thinking. Do we have the right mustard for the vinaigrette I'm making later? Exactly, dude. How long do we have with climate change? Yeah. Trying to think of like all the stuff that pops in my head when trying to meditate. Oh man. Yeah, just such random shit. And then you have one thing that might be valuable. Oh. Should I stop meditating? Cause I need to, I don't want to forget this one. Hey dude.

+ Read More

Watch More

Why Specialized NLP Models Might be the Secret to Easier LLM Deployment

Posted Apr 27, 2023 | Views 2.4K

# LLM

# LLM in Production

# LLM Deployments

# TitanML

# Rungalileo.io

# Snorkel.ai

# Wandb.ai

# Tecton.ai

# Petuum.com

# Mckinsey.com/quantumblack

# Wallaroo.ai

# Union.ai

# Redis.com

# Alphasignal.ai

# Bigbraindaily.com

# Turningpost.com

Why and When to Use Kubeflow for MLOps

Posted Jul 07, 2022 | Views 891

# KubeFlow

# ML Engineering

# Kubernetes

# Mavenwave.com

Just when we Started to Solve Software Docs, AI Blew Everything Up

Posted May 24, 2024 | Views 418

# Software Docs

# AI

# Abstract Group