The Weekly Dev's Brew

Scaling New Heights: Jeff Cross Discusses NX, Monorepos, and the Future of Development

• Jan-Niklas Wortmann | Web Development Enthusiast & Podcast Host • Episode 10

Share episode

Join us in this insightful episode of The Weekly Dev's Brew as we sit down with Jeff Cross, co-founder of NX, to explore the evolution of monorepos and their impact on modern web development. Jeff shares his journey from working on the Angular team to launching his own successful ventures, offering a unique perspective on the challenges and opportunities in the tech industry. Discover how NX is transforming enterprise development with JavaScript frameworks and what the future holds for open source and AI in software engineering. Don't miss this engaging conversation filled with expert insights and practical advice for developers and entrepreneurs alike.

Our Fantastic Guest
Jeff Cross - Co-founder and CEO of Nx.
X (Twitter)
LinkedIn

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

How was the shift for you from being a developer on the Angular team with the very public side of things to the fundamental idea, well, you know what? Let me start my own business. I know this thought occurs to many developers, but not a lot make that jump. So how was that for you? It wasn't the first time I had a company. So, like, actually, I started my career. I started web design, like actually designing things and implementing them, like less on the programming side but more on the design side with HTML and CSS and Photoshop and all that. Dreamweaver back in the day. So this was like back – like I started – my mom was into web stuff. Her job was an intranet webmaster. So she taught me pretty young when I was, like, 12 years old. And then when I graduated high school and was, like, doing college but not really sure, I was doing web development on the side for people for a little bit of money, much better money than I could make at another job. And I just, like, wasn't really vibing with college. And so I quit and just said, okay, I'm going to – I started a web design firm and ran that for about – so that was like 2004 to 2008. Yeah. I was doing the same thing at that time. Yeah. I don't want to know how young you were then. But so that was the first one. And then I went and joined – I took a job at another – at an agency that was doing really cool stuff with web and Flash. And then I worked another job. And then I started another company called Deployed with a friend. Deployed where we removed the last E. And this was like an open source back into the service. It was kind of when the other ones were getting popular, like Parse, Firebase. Like, we were in that kind of cohort of people building back into the service. It got some good traction, but we weren't able to raise money. And so after a year, that's when I went to Google from that job. Like, we had at least built a little bit of a relationship with the Angular team because they were pretty early at that point. And we built some integrations with our platform with it. So I met Brad and then went to Google. So this was like the – I had learned all the things not to do on those first two companies. Like, they were great. I mean, they gave me a living for a while and lots of good experience. But then starting – then, like, we got to a point at Google where I was just getting that itch again to be like, okay, I see this really big opportunity. And it's – like, the opportunity is so big that it's worth me risking, you know, leaving one of the best companies in the world to pursue it. Tell me more about that because if I look at it – like, I mean, you started a company for mono repository development, which is very much a scale issue. I mean, obviously. So you're literally just targeting – just targeting the very big of the big companies. Are we, though? Are we? Well, so I would like to – because, I mean, the experience that you gathered at that time is from Google where you have, like, a bazillion developers with a bazillion lines of code. I'm just challenging you. But you're close to correct, though. Well, I don't want to spoil my own question because you know I use NX for literally everything. I do a Hello World application with NX for a conference talk. And I should note that you and I have a friendly rapport. And so I'm allowed to – Well, you still owe me $20 now for that ad spot. Okay. All right. But, yeah, Victor will give you that just to follow up with him. Okay. Okay. So actually, we started the company without monorepos even being near, like, what we were thinking about. We started – but we did start saying, okay, we're going to help large enterprises move to Angular 2 and in the process also help them figure out how to develop at scale. Like, what are the patterns? How do you – what's the architecture? You need to help my memory because I – you started with Novel, you and Victor. Or – and you were – you built NX on top of the Angular CLI. Or did you before focus more on the consulting side of things? What you just mentioned. We actually – we didn't even have the idea. We knew we wanted to build something like NX. But we weren't sure what it was when we started the company. We really just started saying, okay, we like – Victor and I liked working together on the Angular team. And we saw this big opportunity with Angular 2 just being released. We knew a lot of big teams were going to need to move to it. So we said, okay, we want to build something. Let's actually just get out there and try to get consulting contracts and get Angular support contracts with these companies and figure out what it is we should be building. And we were actually pretty – I don't want to say lazy, lackadaisical. I don't know. We weren't like that aggressive about it, about building something of our own because we already had Angular that we were like the best people in the world to consult on it because Victor built most of Angular. But then we got out there and we started working with banks and other large companies like banks, financial services, airlines, communications, like all these big industries, insurance. And we saw these things that– these patterns of how they were developing things in different repositories and integrating them later and all the pain that comes with that and things just not working and teams building things in silos, lots of duplication. Like all the things that monorepos solve. And we kind of – we had a lot of back and forth to say, okay, this is – we don't want to advocate monorepos because people don't use monorepos for a reason. They're like – like they step on each other's toes. There's not really tooling to facilitate it. Google does it because they built a whole tech stack to support it. And like the developers are indoctrinated in it from day one when they start. They may not have experience in any monorepo, but at Google it's one monorepo for pretty much everything in the whole company. And so that's when we were like, okay, there's really no other way to solve these integration and these pains and these siloing problems other than actually moving them into the same repository together. And so we started to build NX as just an extension for Angular CLI. That's what it means is Narwhal Extensions for Angular CLI. And we just kept building on it. We started working with a bunch of customers. We started hiring a bunch of people. And so we were getting all this input from working with – most of our paying customers were rather large, like some medium-sized businesses, but mostly large enterprise. And so we just kept making NX better from the patterns we were seeing needed at these companies. But, yeah, so I think back then, I think it was like large enterprise was definitely the– but there's a lot of nuance to how we talk about monorepos. Because really now NX is a thing that – monorepos is a great way to describe it, but it's such an overloaded term. We think about monorepos in a way that's like every company has at least one monorepo, like one primary repo where the magic happens. And then there are satellite repos around it where other interesting things are happening and they have some kind of connection, dependency relationship with the Sun repo. And many companies have many monorepos. Like some of our clients have hundreds of NX workspaces and they're all like legitimate, pretty decent-sized monorepos on their own. But we actually – startups are the ones where it's like, okay, yeah, you should have a monorepo because why not? Like you need to justify not having a monorepo. If you've got a team of like 15 engineers working on something together, that would be silly to not work in a monorepo. But large companies, it's a lot more interesting. It's a lot more bespoke. I do like the fact that there is the sentiment with NX. I treat my projects and stuff as a monorepository because it enforces good architecture throughout that. It makes boundaries very clear. So particularly if you work with like offshore companies or just in general have high fluctuations, it's very easy to like you work in this boundary, you work in this boundary, and it's very distinct from another. But you still have all the integration capabilities with one another. Yep. Hey, I agree. I figured you would agree. I am curious though because like being part on the Angular team, super technical job. I mean, you are a pretty face, but it's still a very technical job. Thank you. You're welcome. So how is that shift from, I mean, you kind of had it before from like running a company to developer and like primary developer. And I think these days, correct me if I'm wrong, but you're not day-to-day writing code anymore. Have you looked at my GitHub graph? There's not a lot of green on there. Let's just assume you have a private company account as well where you actively work on. I don't do any. The thing is like I'm not, like I'm a decent programmer, but we have, our team is so much better and so much faster that if I actually get involved, I slow things down. Like if there's anything that's like, okay, I'll take this on, then it's like I get interrupted by so many things that, like, so one is like I'm constantly disrupted, but also it's just like I'm not as good as the developers we've hired. I'm good at a lot of things, but that's just like they're better than me, which is great. Do you miss coding though? I do it for fun, especially with all, like Bolt is really fun. I don't have any equity in Bolt, but I do want to give them a shout out. It's a super, they are friends of ours, and it's really cool to see Bolt after all the work they've been doing on StackBlitz, making it so amazing for all these years. And then Bolt is kind of like this overnight success, all their work kind of culminating into that. But anyway, so I do like writing my own scripts and code and things like that. I don't really miss building applications. I really like tooling in general. Like performance is always the thing that's been a passion of mine. So now when I see performance opportunities, I usually pair with someone and say, hey, let's profile this and let's see if we can make it better rather than me trying to understand everything about it. So I love the role I'm in. It did take an adjustment, but I do love just being around super smart, capable people. I bet. I would like to talk a little bit more about that adjustment because what I love about development is like you have those moments of joy. Very frequently. Like you also have like this huge moments of depression where you're like debugging something and it's still not working. But like it's very easy to get into like an emotional high of just like, oh, okay, it's finally working. What I've been working on for the last two weeks. Yeah. And as CEO of a company, I mean, you maybe have like big deals that are getting signed that I can see is like a huge moment of relief in a way. But how do you like adjust your value system and what motivates you in a way? Does that make sense? Yeah. Yeah. So actually like Brad Green on the Angular team was good at helping me with this mindset because I asked him the same thing when I was on the Angular team. Like he's an engineer and was not doing any engineering. And he was like, you really just have to go into the day knowing that the value you bring is not in building stuff, but you are bringing value in helping like whatever your role is, like unblocking things or helping big initiatives get formed and things like that. You just have to make sure those are the right things to do and then consciously tell yourself like these are the things. And I do like to find things that give me that kind of gratification. Like, you know, I have a to-do list. I like to check off things. But I do plan every day. I'm looking at what's the highest impact thing I should get done today. And usually there's some milestone or deliverable or something where I can say, you know, I want the first draft of this document to be done or something. So there are still ways where– and deals getting signed are always great too. The deals getting signed is such an interesting thing because it's such a long process with enterprise procurement. And like if you see in movies, like people negotiate a deal and they shake on it in a conference room and everyone on the team just like, yes. But it's like it's such a gradual process of many contracts getting signed in some kind of order and chasing down people that it's like it ends up just being a docusign that you finally signed that gets the deal done. And it's like, yay. But no, we do celebrate as a team. It is great. But it's, you know, not like you would think. So you don't have like the Wall Street bell when there's like a big deal coming in? And it's not you and some other firm competing at their headquarters for the business? When you said one other firm, that kind of reminded me that the – I don't want to call it competitor because it's not really fitting the vibe. But you do have competition with Lerner in that space before. Well, in business terms, you would say you acquired Lerner, but that's also not quite the case. We took over stewardship of Lerner. Do you feel this is to some extent like a conflict of interest? Do you feel that might be a perception of the broader public? I don't – there's nothing about it that I think constitutes a conflict of interest because we made it better. Like we – you know, we took– not made it – like there were people who were maintaining it who were just not – they didn't have the time to do it. And so we took it over. We replaced some of the underlying things with NX. But we didn't change actually much about how Lerner itself works. Like we – when we took it over, I made it clear like, hey, look, we're not trying to like – like we really – we really want to support this kind of different paradigm of monorepos. And we called that more like package-based monorepos, whereas we called ours integrated monorepos. NX has evolved a lot since then. Now it's – like there's not a real distinction in NX. But we did see an opportunity to take that over, foster some goodwill in the Lerner community. The NX stuff was mostly hidden unless they wanted to migrate to NX where all the magic is. But so it was mostly just underlying things that – like James Henry on our team did a lot of work, some other folks on our team, to make it good and keep it up to date and make it faster and add some things that the team had wanted to add to it that they just didn't have the time for. How is there a conflict though? Like what do you see as a conflict? Because that never crossed my mind. Well, if you look at it just like on a 10,000 feet level view, those are two packages for monorepositories. So in some way you could argue that you're basically like taking your own business away. In a way. And very, very black and white. Yeah. So we never saw it as like – we saw it as a maintaining thing. We didn't invest a lot in growing the Lerner community, but we wanted to take care of the existing community. For people who are moving to monoreposit tooling, NX is the obvious choice. And we did want people – if they ever did want to move off Lerner, it is an easier path to move to NX. So really, we didn't see it as competition more as like it's something we will keep making good but not really market it and promote it. I like that way of thinking about it. One thing I'm curious now to get your perspective as a CEO on the topic of open source because parts of NX are open source. NX cloud is not so much open source. No, nothing about NX cloud is open source. Where do you draw the line and where do you say, okay, for these parts it would make sense to have those open source? And I'm also particularly curious in the reasons behind that from your perspective. Yeah. So there are a lot of different ways you can do commercial open source. And probably the most popular one is the open core model where you have some kind of pluggable architecture and then a couple of free plug-ins and then like the really enterprise-y ones with more access control or like supporting Oracle databases. Things like that you would have as proprietary plug-ins you charge for. Or ours is not quite that. Like you could kind of squint and see it as some version of open core. But what we ended up with, which I think is pretty good, is we have the cloud part that does cloudy things that is completely proprietary. So, I mean, there are some things we do that enable you connecting to other clouds other than ours. But it's just nice that anything that connects multiple environments goes into the cloud product. And the CLI and plug-ins are all focused on a local experience. And so console, like NX console, our plug-in for JetBrains and for VS Code. Who knows? Who's ever heard of VS Code? Never heard of it. But those connect with our cloud and with the CLI. And that's kind of its own. It's proprietary but free. I mean, I think it's open for... Well, and the code is public. I've seen at least the code of the JetBrains plug-in because I checked something for you. Yeah. So, I think it probably is in the main NX model repo. I don't know anymore. It used to be its own repo. Yeah, I'm not sure. It could still be. But anyhow, yeah. So, it's like... I mean, it's not something that really makes sense to fork. But, like, it is for you. It is out there. So, really, yeah. But it's worked out nicely for us because you can get really far with the open source plug-in. There's lots of community plug-ins, lots of our own plug-ins. They're all free and open source. And then when you want to connect it and take advantage of all the amazing things we can do, all the optimizations, all the ease of use, all the analytics and things like that that we do in cloud, you'll hopefully subscribe to our cloud or buy an enterprise contract from us. But when do you decide, okay, this part should be open source? And because I... You're much smarter than I am, so I don't think... I know, yeah. You're just looking at the free labor aspect of things. Oh, no. Free labor is a myth with open source. I 100% agree, by the way. It doesn't make sense for anybody to do open source for free labor. You spend more... You do more work that way. So, I'm trying to think if there's anything... Okay, we do have one thing that's not... Like, we have this thing called PowerPack where it's, like, some enterprise-y things on top of the CLI. Like, enforcing conformance rules across a bunch of repositories. Like, we decided to make that commercial because it really was something that... Or, of course, we can enforce rules in one repository or many repositories. But that really was something that was, like, very enterprise. And it was, like, okay, this is going to take more work for... This is actually part of our cloud product that we're making available to use without our cloud because everyone needs this stuff. And so we said, okay, we'll charge for this. We'll charge for seats for this. I think that's the only thing I can remember that's ever been kind of ambiguous. But most... Like, our CLI team, the open source team, they don't... They've spent a lot of time just on the open source. Like, they don't think that much about the business. I mean, I shouldn't say that for, like, if investors are listening. But really, like, they just think about how to keep making the CLI better, how to keep making... Like, they're not thinking so much about monetizing things. And we really do focus on making the cloud such a good product that more people want to buy it. And to be super honest, I do have that impression every time when I talk to someone on your team. Not without... I'm not saying names because then you might be like, what are you saying? But they are very focused on their area of the product and trying to... Like, their landscape and try to make that the best, whatever that means for that part. And I mean this in a generally good way. Yeah, it is a balance. But we want people to kind of rotate and be thinking holistically. But also, you get a lot more done when you're focusing on one thing. Yeah. Just to sum up what you said, basically means open source by default unless there's a business incentive. Really, the rule of thumb is that if something makes sense as a connected thing, it goes in the cloud and it's commercial. If something makes sense as like a local experience, then that goes in open source. Are you concerned? And no is a very valid answer that someone now goes... And I mean, we've seen VS Code Forks pop up left and right over the last couple of weeks. That someone is now like, oh, you know this NX Cloud thing? That seems kind of interesting. And I'm pretty sure like I can AI generate something for that so that they just take NX as a core, fork it and build on top of that and actually become a viable competitor to yours. I mean, people have done it. And it's annoying when people fork something because you know they're not going to invest in it as much as you have. But they're going to create noise in the community. But it's like just part of life. And, you know, I've been doing open source for, I don't know, 15 years now. And so it's over several popular projects. And so you just kind of get used to those things. And people do build cloud competitors, too. I don't know them that well. But they're welcome to do it. I don't mind it that much. Our cloud is so much better and so much more enterprise ready that it doesn't... Like our bread and butter is successful businesses, like successful startups, successful enterprises, people who, you know, take security seriously. They take performance seriously. They have massive teams who they need to eke out every little bit of optimization in their dev workflow. So it doesn't concern me that much. It doesn't really show up on my radar anymore. Your background is just perfect because with the consulting you did in the beginning, you get like, A, good connections to a big company, but also just like good experience, as you said before. And now you can use that as a leverage. Yeah, lots of great things came from that. Okay. What is your stand on consulting as a business model? I'm really glad that we did it. And like, so the best thing about it was, I don't want to make it sound like it was easy for us to get the business off the ground, but it is like a somewhat straightforward. I'd done consulting most of my career other than Google. Everything was consulting other than Google. Not the Google part, but same. Yeah. And so I knew how it was done. And so it was somewhat safe. We had to hustle a lot when we started the company. Like, we didn't have any business lined up when we left Google. And so we had to basically just like email, call everyone we could in our networks, ask for favors and introductions. It's a great thing. And I think it made, it's the reason NX is so great is because consulting is in our DNA. And we continue to do it. Like, we have our, for our enterprise contracts, our enterprise customers, we're really hands-on with them. Like, I go out and meet with them, with several of them once a year or so, and I'm on lots of calls with them other times. But, so we still try to incorporate that and get everyone in the company to still be acting like consultants because it's how we stay connected to how the enterprise developers work differently from us. Like, their flows, their tools, their constraints are a lot different from us as a kind of a nimble startup. And so, so that's, that's the way we keep building NX as the best tool for them is as much exposure as we can to, to how they're working. As a business, I think it's, it's, it's got its downsides. Like, you, you only make money when you're working. I mean, you can structure contracts however you want. But if you're doing hourly consulting, then you have to work. You can't really, you don't get paid in your sleep. All these things that, with subscription products, they all have their own trade-offs. But consulting is a great business. Right now, I think the market's harder for consultants. It's harder for a lot of things. But, but it is, when the market's good, it is a, it is a really enjoyable and fulfilling business. I did consulting for like, not quite 10 years, just to put out similar numbers as you do, to make myself, feel myself better, you know. And I think it's, I do appreciate the fact how much I learned in that time. I'm 100% sure if I stick with consulting and stick with working at a company for 10 years, I wouldn't be where I am now. Having that said, working on a product is, to some extent, more fulfilling. So, I, I personally like the mix that you have, particularly for your people, where it's like a little bit of both. You have, you can have them go out to clients and do work, but you also have the in-house product that you're working on. So, I think that's a great combination. Yeah. I, I thought, maybe I'm wrong with that, but I thought like last year or the year before you announced that the consulting part, maybe I talked to Yuri about it. I, I don't remember, but I, I thought you basically said the consulting part will run out officially and everyone will more focus on open source or cloud. Yeah. Yeah. So that's like when we raised our seed round in 22, that was, yeah. So we, that's when we went all in and we said, okay, we like, we really want to go all in on product because we've got a lot of things we want to do. We just didn't seek new consulting engagements. We, we honored the contracts we already had. I see. Okay. And then at that point, so at some point after that, a few months later, then I think we, we stopped doing consulting at all and just did it as part of our enterprise contracts. Um, so, and that, that was, you know, that's the reason we raised funding is so we could, uh, because everybody's working on NX in their spare time, like 20% time. Uh, and it become a great tool from that. And we were just like, okay, we could do so much more interesting things, uh, with people focusing full time. And so we raised funding raised eight, I think we raised 8.6 million in our seed round. And then we raised an A round, um, a year later at 15 million. And so this really just like, let us take big, bigger risks and, and focus a lot more on, on fast growth. Considering those numbers, you still compare to other startups, you run novel, fairly humble from my perspective. Yeah. Like it's not that you, I mean, you, you hired a lot of good people, but I think the last time I asked someone of your folks, you said, or they said you're around 50 ish people. More or less. Somewhere between 40 and 50. Yeah. Yeah. Yeah. So, so it's not like that you're like, oh, we have funding, so let's hire a hundred developers and get things going. Like you don't have like this hyper growth strategy. Yeah. We don't have hyper growth of the hiring. That's not what, we do have hyper growth, uh, in other areas, but like, uh, revenue and product and customers and things like that. But yeah, we, we, we, we like to keep the team as small as it can be, uh, because a lot of things are just better that way. And, um, so a lot of things are different. Like people wear multiple hats because of that. Uh, like we don't have anyone who's, I don't think like, like our dev managers are actually working on product and managing people, which, you know, you could argue against, but, but, uh, it, it works out. Like it, it's, there's a very few layers of management. Like it's, it's really, everyone can talk to anyone and the more you hire, it just gets harder to, to do that. And so we, we do, we only want to hire when it's like, okay, we really need this specialization or, or we need more bandwidth for this thing we want to do. Um, but, uh, I really like how it is now and we've kept the company. We haven't, the only thing we've really grown is the sales team, customer success team. Uh, and a couple of engineers in the past couple of years, but, uh, other than that, we've, we've managed to maintain the culture. And I mean, at the end of the day, the culture is not defined by how many people you have, but like how you embrace it. So having that said that this wouldn't be a podcast in 2025 if we wouldn't talk about AI and you did something, not you, you, but you as novel. By myself. You alone, just you, uh, did some cool AI things. And you, you literally just said, we don't do hiring if it's necessary. Having that said, you did a busy, or plenty of stuff in the AI space without that knowledge. Mm-hmm. So like the AI space, there are lots of different things you can be in AI. Like, you know, you can actually, you can be like open AI or anthropic where you actually have Google, like you have your own models. And then there's like people who are building jet brains, like things where you're actually like coding assistants. But there's all sorts of other things you can build around AI. Like, like MCP is becoming more mainstream. What was a, and Cursor supporting it. And I think you support it. Yes. Um, I'm sure we're working on it. Um, but, uh, I think, I think Cursor was the first one to, to like, to have a good MCP. Okay. I don't want to go into snarky details. Okay. Go into snark. So, so super transparently, I think from my perspective, and this might, I I'm very aware that this is very biased, but I think we were the first that had an MCP server out there. We had like a first prototype somewhere mid of last year out so that basically tools like Claude or something that supported MCP as a client were able to interact with jet brains as an IDE. It took us a while to realize, well, we can also do this vice versa. And this literally just happened. So, but like from that aspect, we were out there quite early, but we didn't make the, and I think really the popularity of like MCP. Um, service just pop. I feel like it popped out over the last four months where like everyone out of nowhere jumped on that bandwagon. And then it become a viable interest for like tools to integrate more with it. Yeah. So, so what, what's interesting to us is like we, we've seen over the past couple of years, a lot more enterprise adoption of coding assistance, uh, of, of all the flavors. And, um, but our whole thing is like working at scale, like thinking org wide, company wide. Right. And, and what these coding assistance lack is, is the appropriate context to, to do things in a way that makes sense, um, in the big picture of things. Like they can look at the code in your repository and, and, and do some kind of consistent things, but they don't know what APIs exist outside of that repository or what services they should be interacting with or what kind of coding guidelines to, to incorporate. Right. So like MCP, the first thing we did is, is all local and it's like, it's just, you, it gives, it gives, uh, we already have a server running in our IDE. So we actually just built onto that. Uh, like whoever, like the, the team working on this is probably going to listen and say, no, it's not quite exactly how we did it. Yeah. Um, but like NX console already had the guts there for us to build on. And so we, we said, okay, we can actually feed more context about like what, how projects relate to each other. We already have the dependency graph of projects, do things like being able to ask questions, like who owns this part of the code base, who owns what, uh, to where if you even just move to an NX workspace, everything in that. Now our MCP can give a lot more context to the coding assistance. And, uh, but we're, we're expanding that to, to actually connecting many repositories. We, in our cloud the past year or so, we've had this suite of things we've been focused on called polygraph, where we're taking some of the ideas of monorepos and extending it to polyrepos, like meeting enterprises where they are to allow them to have more, more of a higher level understanding of how everything in their whole ecosystem relates to each other. And so what, what we're continuing to do with MCP and a lot of other interesting AI things is, is, uh, giving you feeding context as if you were, as if all these things were in one monorepo, but, but in a nice, in a balanced way where we're compressing where we can. So we're not overloading context windows or giving more information than, than is helpful, but we can give a lot more information about the big picture of how things relate, how, what standards are, what's available, how other people accomplish similar things in different, uh, different code bases. So the coding and systems can be much more powerful. Uh, so the, the, the, like the writing code is not, is not the hardest part of a developer's job. Uh, I'll say like, it's, it's challenging, but. I think people will disagree, but I generally agree. Yeah. What code to write, what systems interact with, where to put it, um, all these things, those are like, those are the things that you spend most of your time figuring out and then you actually write the thing. Uh, so we're, we're, we're helping with that part of it where, where there's a lot more visibility to how your company looks and works and all that, uh, to your coding assistants. There's a lot of other things we're doing are like with agentic multi repo refactoring things we're building on. Uh, but that's, that's one of the more recent things is the, the, like the MCP is just like made it where we can expose a lot of the stuff we already know to these coding assistants. How do you balance innovation like MCP, which is like somewhat cutting edge right now versus like, okay, this is what we met. We have a reliable business with this is what we literally make money with. So how do you balance those things as like CEO of a startup? You really always have to be, uh, I'm trying to think of the right way to say this, but you always have to be ready to throw away or like to rethink your whole playbook. And AI is a thing that's every company should be rethinking it and saying, we can't rely on things working as they were before. Things are going to change. How do we leverage our position to, uh, to be ahead of that and to create the change that that's occurring? Um, so we, I think we kind of lucked out that AI is only good for us. Like it's only tailwinds for us. Like it's increasing, it's increasing the output of teams. And that's like a lot of what teams are paying us for is CI and like value. It increases the importance of automated validation of, of QA, things that we are all like well positioned for. And monorepos are good because you get more context for free. So like there's, there's not, there's nothing I can think of with AI, uh, cause we do think about a lot. Like our, we do think about, okay, how can we keep on leveraging it? How are developers at enterprises going to continue using AI in their day to day? And how can we be ahead of it? And, you know, leading that hopefully. I think there are a lot of businesses who do have to change a lot. Ours, they're just only, they're minor things to, to tweak, but like we just see opportunity on opportunity with, uh, with taking the things we were already being used to. For large scale refactorings, maintaining, maintaining large code bases, validating changes. Like the, those things we just keep making better for AI. I do have to say, like, if you would have asked me about AI two years ago, maybe a little less than that, I would probably have said that it's a similar hype turn than web three. Till I like use it myself a little bit more. Yeah. So how do you engage in those emerging business opportunities? Because like, I mean, I, I, I particularly on this podcast, I be snarky about web three a lot. Um, but there are viable businesses for web three as well. Uh, it's not, there, there is a whole scammy aspect of it, but there, there is a. That's the unfortunate thing about crypto and general and web three is like the, how much. Yeah. Anyway, we don't want to get into that, but, um, I agree. Like the technology is interesting. There are real use cases for it. It's like such a tainted, uh, tainted, uh, industry that hopefully becomes less tainted. Um, so the, like, so like an AI is, I think, like, I think I'm pretty skeptical in general and AI have always been like, I've always been excited about AI for, you know, for the past 15 years or so. And, uh, like, and like at Google, there were lots of interesting things happening while I was there with, uh, like the acquisition acquisition of, um, what's that DeepMind? What's it called? The AI company in the UK deep mind. I forget what AI, there's all these things, whatever the company is who like built the alpha go thing that, you know, beat a human in, in the game of go. Uh, but anyway, like in the transformers paper, I think came out while I was there that really like accelerated. Uh, large language models. Um, so it's like, I've always been super excited about AI and machine learning. And I think the, the thing that needed to be proven was how far LLMs could go as tools for every aspect of life, I guess. And I, I think I, I was pretty optimistic that, that it, uh, that there was a lot that they could do or that could be done, uh, with LLMs before the, before we move into like AGI. Yeah. Yeah. Yeah. Yeah. Yeah. And I use AI, I mean, I use AI all sorts of ways. Like, so it's like, I already saw the value myself and could look ahead and say, they're going to get better. They keep on iterating and making the models better, more accurate, more powerful, more capable. And so it, it wasn't a very hard guess. Uh, like it, it wasn't, there wasn't any real speculation. It was like, no, this is going to transform everything. And, uh, development is not, uh, not, uh, excluded from that. So we need to, uh, we definitely need to be thinking about how it's going to be changing. I think we, to be honest, I think we moved a little too slowly on things because we really do, we only want to do things that are practical. And we were kind of looking at how, like we, we were looking at how teams were starting to adopt it and how we could make sure we're supporting that. But, uh, it really is in the past six months that we started getting a lot more aggressive about building our own, uh, our own stuff with MCPs, but also our own, our own capabilities into our platform that leverage AI. It was last year that you announced the NX agent model, right? NX agents, it was like a CI thing. So it's a, it's an unfortunate name because CI, CI machines were called, are called agents in a lot of cases. And now there's like agentic AI that kind of overloads it. So our agents is purely CI. But wasn't it, okay, maybe I'm in that boat of people mixing things up, but I thought it was an AI approach for automatic scaling of those agents. Yeah, so there is an AI component to it that, that, yeah, we, and we're, that's something we're always iterating on where pipelines, like pipelines traditionally in CI, you configure a pipeline of an order of things to run. And then you'll spawn out some agents that you delegate work to. Uh, sometimes you'll skip the work if you decide to, we basically remove all that and just say, trust us. Like we'll, we'll figure out the machines, the machine pool that needs to run this based on some parameters you've given us with cost. And then we'll figure out the size, the number of machines. And then we know everything about how your tasks depend on each other, how long they take, what's cached, which ones actually need to be run based on what's affected. And we just do it all for you. So, uh, and AI, we keep on, we're using machine learning to keep on training, uh, to say, okay, instead of us just like kind of teacher sizing, how big a pool should be, like we can get more precise based on even more, more data that we're training. Yeah. What, if you want to share some of the things that you're particularly excited about NX right now that is in the pipeline, is there anything that you want to tease a can teaser would like to teaser? The thing I'm most excited about is the poly repo stuff. Like the, like where we're taking, we're taking the ideas of modern repos and giving you a modern repo ish experience across many repositories. Like things like you can, you can run CI across different repositories. If, if, uh, like if you have a design system in one repository and like application in another repository, the, you could set it to the design system triggers, uh, triggers CI for that, or triggers like a sample of other projects that depend on it to validate that change instead of just relying on their tests. There's just a whole lot of things that come with connecting these repositories, like dependency visibility, uh, for security, like having a better understanding of how everything is connected. Uh, both first party and third party and being able to quickly run changes. Like if there's a CVE or something like, like the log4j CVE, like you could, with, with what we're building and like, where it's already, like a lot of it's already there, but there was a lot more we're building. You can see, uh, you can see who's using log4j at what versions. And you can actually tell NX to say, okay, update all these repositories to like this version of log4j. And it's going to submit a pull request to all those repositories for you. Like that's the kind of stuff that we're working on now that, that will soon, that will soon be publicly available for our enterprise customers. But, but like, there's just so much stuff that is unlocked by us really breaking into this, not just monorepos and like let's connect more, more things. And, and like, there's a lot of powerful things we can do to, uh, to make teams able to move a lot faster with a lot less effort. I think what you said, the poly repo aspect is particularly interesting for like the more medium to like small, medium sized company, but also still to like the big companies. I'd say the opposite. Okay. Like, I mean, some of our, our customers who have several NX monorepos, like they're, they, like some of them have thousands of different repositories and they have no interest in consolidating them. Right. But like what I'm thinking is those big size companies usually have like an infrastructure team or something that monitors things like that. Whereas on the smaller side, you, you don't have like the same scale. But they don't have very good tooling right now to, I mean, they have scanners is about as far as, yeah, like. Yeah, that's true. But they don't, they don't have the kind of tooling. That's true. So they, they lack a lot of visibility. Uh, things are, uh, so, but that, that, that is who we sell to is platform engineering teams. Like some overlap with DevOps teams, uh, and IT teams, but, um, yeah, those teams who are responsible for a bunch of repositories are really who, who, uh, keep us in business. And, uh, usually you have a big conference. I think you, you change the name every year. So it's hard for me to. We're going back to NX conference for the next year. For real? I thought MonoRaple World was a great one, but. It, like, the thing is it was just NX conference. Like in it, we wanted to, we had some folks, some friends from community, uh, giving talks from other build systems. But it was just so much NX and, you know, we, we paid for pretty much the whole thing. And, uh, so, so it's kind of like, okay, let's just make it less ambiguous. Call it NX conf. Do you have a date already that you would like to share with an unknown number of audience? No, we're working on figuring that out. Okay. My, my guess is it won't be before the end of this year. So a normal layman's term is will be next year. Or it will be at the end of this year at the very end. Is that what you're saying? I doubt it will be this year. Okay. We actually, we were planning one, but we, we, like some things happened with the venue and, and I had a change of heart on, uh, on some things. So like we were, we were going to do it in DC and I'm just like, I was like, I don't know about DC. You know, it's kind of, kind of, kind of awkward now. So, um, so, so we're rethinking it and like, we want to, we want to plan well in advance. Uh, and, uh, running in-person conferences is hard. So I have nothing but respect for that. There's a reason that we do it online. Yeah. Yeah, it is. We have good people who, who work on it. We did do a European one, uh, in April. Yeah. Uh, in Amsterdam, like a small version, but I mean, it was actually about the same size, but it was a great success because, uh, you know, Europeans don't want to travel to the U S necessarily. So we, tell me more about it. That was a lot of fun. Last question before I let, and then I promise I'll let you go. Do you think that stigma that NX is an anger tooling or like anger for enterprise is still around? Is that something you're suffering from? Because, um, I mean, I, I've said it before. I use NX literature for everything. My, my website for this podcast is using Astro. It runs NX. My every sample application. I know last year, you announced that you also do Nuxt support now. So it's not just anger, but the stigma to some extent, is that still there with you? Are you suffering from that in some extent? I think it's, I think it's like, we do, we do benefit a lot from it, but the stigma, there is definitely a stigma with people who hate Angular or who not hate Angular, but like see it as kind of a, like not as hip or I'm not, I'm not trying to be condescending, but like, like it's more like enterprise or whatever. I think that's a valid public perception of Angular that some people have. I'm not saying this is necessarily true, but yes. Like Angular has always been like the enterprise has been its strongest adopter. Yes. Um, so I think people who've known of NX for a long time, that kind of still exists. Like if you ask somebody who's not using it day to day and be like, oh yeah, that's the Angular monorepo tool. Right. Uh, I think, I think anyone who adopts it now, like the, the NX community is still growing quite a bit. And, and also as we expand to other languages, those become less, less, like there's nothing on our site or in the tool that's, that would indicate that this is an Angular thing. And like, we don't spend a ton of time. Uh, we don't spend a ton more time on, on Angular support than any other kind of tool. So I, I think, and that's just something you have to accept that, that I've learned is that like, uh, whatever, whatever impression people have from when they first learned about your product is it takes a long time for, for them to, uh, get rid of that impression. And a lot of work, a lot of repetition and a lot of exposure. Um, but, uh, you're never going to get through to, to everyone. Yes. But it definitely has been a thing that like other tools have tried to use against us, uh, like turbo repo that when they came out, that was one of the biggest, uh, one of their biggest talking points, um, which, you know, which is funny because now they're just next.js. Yeah. Um, well, I, and I think they, they were, I think they had said they were going to support Angular, but I'm, I'm sure Angular is just so, so bespoke. It's, it's, uh, still not super easy to build tooling for, but, but yeah, so, so I, I, I, I don't think it's too much of an issue anymore. Awesome. Jeff, Jeff is your name. Yes. I don't think I ever called you Jeff. You have three names and I never, I never know which one to use. Usually call you Mike Hardington. Just to poke the bear, you know, and I'm also very jealous of that beard. So it's a little bit of a homage in that sense. It's a lot more peppery these days. Looks good on you. Thank you so much for joining me. This was really great. I always love talking to you, but you're, I love your career perspective. I love the way you think about open source. I love the way, and I even more so love what you're working on or enable with NX. So thank you very much. And thank you for joining. Yeah. Likewise. I hope you had a good time. Always happy to chat. I did have a good time. I always do have a good time. Good. Good. You always have a good time. Not on every podcast, but every, most times with you, I have a good time. Okay, good. I appreciate that. Most times works for me. It's better when Jennifer's around. She kind of mellows you out a little bit or balances you. Yeah, that's fair. Well, I feel like when Jennifer's more around, I'm more like my grumpy German side. And you can take this as you want. Whereas like, in like this, it's more like, as you said, like mellow. Yeah. Yeah. Thank you again. I appreciate you. And I'll probably run into you soon. Hopefully. Bye.