GitHub Copilot, Clean Context, Automated Testing & AI Coding Agents with Lars Gyrup Brink Nielsen [MVP]

Welcome back to the M665FM podcast. Today we are talking about one of the biggest shifts happening in software development right now. For the last few years, AI assist development has largely made out of complete code generation chat interfaces. And yeah, and give some co-pilot to the people. But now we are entering a different phase. We are moving from AI that helps developers write code towards AI agents that can perform development work. They can inspect repositories, understand issues, modify files, run tests, reason over failure, create and pull requests, and potentially work through entry engine task. And that's changed the problem. Because one of the AI agents starts operating inside a large product code base. The biggest challenge is no longer simply where the model can generate wild, type scripting. The request to become what context does the agent receive, how does it understand the architecture, how do you set now your team standards, and how you stop it from making locally correct, but architecture of terrible decisions. And how do you verify that the work in products is actually safe and merge? My guest today is Lars Bureau Brink Nielsen. I always manage writer. That was pretty good. Thank you. Microsoft MVP in development technologies. And X-Chemchin, Github Star Aluminum, book author, international speaker, take writer, resource, meditator, and community organizer. If I have forgotten something, you can correct me. Lars has extensive experience across from development, cloud native systems, debodder parks, periods, out of maging, testing, continuous delivery, and deployment. And yeah, what calls a "gentake experience" is also been working with Github co-pilot since early days, and he spent more than a more than a year automating open source software development. More recently, Lars has been codified team standards, especially for a eye-coding agents, and one of the hardest problems in large mono-respresenting clean context. So today, we are going deep into Github co-pilot, type scripting, and X-play, write, automated testing, and so on. Yeah, Lars, welcome to the ELX-65 podcast. I hope I haven't forgotten anything. Thank you. There's always more about that. That was a lot. Thank you for remembering all of that. Yeah. Lars, before we get into the AI agent topic, let's start a little bit with your background. You worked across very broad range of development technologies. What organically pulled you into software development, and why did JavaScript become your favorite programming language? Oh, then we have to go a long way back, because I guess already as a child, I got interested in computers. I'm from 1986. I just turned 40 years a few weeks ago, and got my first Commodore 64 as five years old boy, and that's what got me hooked, basically. I couldn't program, but just having to enter commands on a keyboard and insert cassette tapes and things like that, that was just really, really interesting to me, to get to play games. And then I started tinkering with computers back then, as you might remember, it was not that easy to set up and install drivers, and install windows and operating systems, and all that. It was not nearly as easy as it is today, so you had to know a thing or two about computers and how they work and building your own hard, collecting different sets of hardware, like the motherboard and the RAMs, and everything had to fit together, and you had to plug them in and connect them to the case and all of that. So I'm really interested in that type of engineering work, and how things work generally also been into engines, but that's for another discussion. But what then got me interested in programming itself was when my neighbor visited me, and he had just started in the 10th grade, and they had an HTML course in his school. So he taught me the basics of that, and that's, I never stopped from then, and that's 25 years ago, 26 years ago. So I always knew that I wanted to be something with computers. I didn't know what, exactly. But I ended up studying computer science, got a bachelor's degree, and then I've been working professionally with software for 14 years now, but I was really tinkering with it for, yeah, 25, 26 years doing hobby projects, and hand coding HTML, and CSS, and JavaScript, and even before, there was any CSS, and there was barely any JavaScript, and so on. And then you're asking me, "Miracle, how did JavaScript become my favorite language?" Well, it was just always the web platform that intrigued me, since my neighbor visited me and taught me HTML, and I could get something on the screen on my own, just by writing something in Notepad, and then opening it in a browser. That was really, really cool to me, and you could view the source of any webpage, copy some snippets, and tinker around like that, and make it look like things that people know, like giving in a Windows XP theme on your website, things like that. So, yeah, that was really what got me interested, and then I just kept going. When I was studying computer science, it was the first wave of mobile applications, but I still wanted to bet on the web, and today mobile applications are more common, but back then it was sort of a bubble at first. Everyone was doing mobile applications, but then they stopped for a while. Now it's more common again, but for many years, that wasn't the best idea, and the web apps were more interesting. And I still think web apps are more interesting, and they can do almost the same things as native mobile apps, from my perspective. Well, you have so many experience in JavaScript. How did the ecosystem like when you start and what is today? Yeah, well, when I started 15, 16 years old, I didn't have a code editor, I was writing a note pad. I even wrote pen and paper, PHP code, for example. And then I had to imagine how that worked without having a real server in real computer. I took some pearl courses as well, outside of school hours, and so going, coming from, that was the most basic form of programming or web development for me. And then when I got into professional development, let's see, I think it was around the time where you had to have backward compatibility with Internet Explorer 8, and sort of the first, a second round of application frameworks in JavaScript, were just coming along. It was AngularJS, was big view, no, not view that wasn't there yet. Ember was then the first version of React was released a few years later, or around that time. And responsive web design was pretty, pretty new. And I remember we were rewriting a big software system, and my CTO at the time thought it was a waste of time to make it work on tablets. Nobody wanted to use it on tablets. And my perspective was, well, if they don't want to use it on tablets, it's probably because it doesn't work on tablets. Maybe if you designed it responsibly for tablets, even mobile phones, even mobile first, then maybe people want to use it. The users want to use it because it's a pretty good experience, right? And of course, that turned out to be right, as I see things. Yeah, it's funny. I started nearly the same way, but I make all the wrong decision you can do. I think first it was a Dolby Flash, I think, then Silverlight that I do it is a CSS course, but yeah, you have done the JavaScript and a TypeScript. Why become so essential part of your development workflow? TypeScript in particular, or JavaScript, or TypeScript? Well, I didn't choose it in the beginning of my career. I had to pick a framework. Well, I actually initially, I didn't, I also didn't pick AngularJS. I picked something called Nugout. JS by people, some people at Microsoft, Steve Sanderson, a few other people. And with a small JavaScript framework, you didn't have to compile it. There was a template language, similar to what Angular, the modern Angular has today, but it worked at runtime. Of course, that also set some limitations for how complex the application can be. But they did have one good primitive in Nugout. JS. They had observables, and that was before Angular got obsessed with RxJS observables. But unfortunately, they also had two-way data binding, which turned out to be not so scalable for big applications. But we were really just getting started back then at what was possible. Single-page application was a pretty new concept to do mainstream. I mean, Gmail was one of the first success stories of that. That was some years earlier, but to do it in an enterprise setting was still relatively new, and not something that was a given, that you could do as single-page application in JavaScript. No, no, you could just use the server-side technologies like ASP.NET, then PHP, GlareVel, and Ruby, and Python, all of that. Oh, yeah, Ruby arrays. Oh, that's what I was all about. Ruby and Rails, Django, things like that. They go at all times. Yeah. Normally, I ask your MVP, I ask about the MVP title by the year. You have so many other titles. The addicts champion, you are a GitHub star, you are also an outro, a maintainer, and community organization. How important has Open Source been shaping the way you think about software engineering? Well, just a small correction. I'm not a GitHub star anymore. I was for four years as a zone, I'm an alum, so I'm just mentioned as a form of GitHub star. So I'm not directly involved in that community program anymore. I am an active Microsoft MVP, as you mentioned, and have been so for, I think, seven years straight at this point, I'm involved in the NX Champions program as well, around the NX tool chain, and now the Polygraph product, which is brand new from the NX team as well. But yeah, Open Source, well, I love Open Source. I love Learning in public. I love the idea of Open Source. I like building things with Open Source, and especially now with AI coding agents, where you can actually sit one person and get a lot of stuff done, because of the amplification that the AI coding agents gives you. So now I'm trying all sorts of things. I've been doing that for more than a year now, just things I couldn't do before, because it would take too much time for me to invest in my personal time just to learn something, and then be able to do it. Now you can either the AI already knows, or you can point it to some documentation and books and articles, things like that, and then it can learn in a matter of minutes or hours. And that's what's insane about AI coding agents, that it really gives you superpowers. It becomes superhuman. And yeah, circling back to Open Source, well, I have contributed to Open Source for, I think, 12 years or so. I've been part of a few Open Source teams. I still make contributions every year to various ecosystems like Angular, I maintain some Angular, testing and logging libraries as well as state management. And I do a lot of personal Open Source projects, just because I think it's interesting and because I'm suddenly capable of doing things I didn't, I hadn't learned yet before. For example, I just created a type checker for the Angular framework where it only does type checking. So it doesn't do the build or the compilation. It just does the type checking step, but it does it fast and then combine it with this NX tool chain. You can do it per project in a large code base and then enable NX cashing on top of that. And that gives that that's really good for an AI because that helps it the way of making a static analysis of the code really fast for particular slice of the code. >> Yeah, yeah. Before I start a record session, I look a little bit about my guest and I also use AI and normally I ask, "What is the term?" The guest, he was frequently, and for me or for the AI say, you use the term development experience quite a lot. >> Oh. >> Well, that's correct, definitely correct. I didn't know that I used it a lot, but it's definitely what I've been focusing on a lot professionally, especially. >> What do developer experience actually mean to you? >> I don't have a definition ready, but just on top of my mind, but to me it's removing friction in the tooling you use in a specific code base or within a team or an organization. So for example, I have been in a lot of so-called systems teams or platform teams where we have built software to enable other teams to build software on top of that software within a company, large organizations usually. So we would set up the tooling like CI pipelines and automate testing frameworks and NX and dot-net solutions and all that kind of stuff and then make reusable packages for setting up new projects, documentation, how to courses for writing tests and optimizing the CI pipelines again and picking a date time framework for dot-net and all those kind of things that makes the other teams support them in having to, yeah, they can spend more time writing product code and they might not have a big knowledge in this area of all these tooling and schematics and testing and all of that, but when they get these reusable software components, then it becomes easier for them and you have unbought them and then they can spend more time doing what is the priority of their team. Interesting. I think a little bit what for you, it's a poor developer experience, what is a good one and what separates it from an excellent one. Well, I'll give you a couple of examples of very poor development experience. So one you definitely have tried yourself, it's deploying to production via FTP. So you take, for example, a PHP files or multiple usually and you'll just upload it to a production server via FSP and then you check did it work or did I just break production? So a lot of setups used to be that many many years ago at this point and sometimes you would even sit and edit or I saw some people sitting and editing the code directly on the production server. So there was not even source control, it was just edit the file on the server and then you hope you have a backup and there's no version control. That's a very poor developer experience. The room for the margin for error is so big, there are so many things that can go wrong and will go wrong. And would you say makes a good one to your nearly perfect awesome, I don't know, to to to outstanding, I say, I use out, I use out, well, I'll just give you one more poor example. So I was at a web or web agency or e-commerce agency, we have many clients. And so when you would start work on a client's project, there was a shared file server in the internal network. So and there wasn't again, there was no source code, no version control, not that they didn't exist. This organization just hadn't adopted them. There was no Git, no subversion, nothing like that. So instead, they would make a zip archive of the source code and then put it in the shared file server. So when the next person came, they would take that zip file, copy it to their own machine, unzip it, work on the code, zip it back, put it back on the production server, override the existing file. But then sometimes, I don't know if you can guess what happened. No, no. You would have to start working on a project and you go into the file server and there was no file, there was no zip file, no source code, because instead of copying the file, the previous person had moved it to their own machine and not put it back. Oh, how often this, oh yeah, fuck yeah, this was so often then. That's that support developer experience. Well, yeah, I really forgotten this, oh my god, this was so often. And what would you say make good to, to ask me? So what's a good developer experience? Well, these days is it's a lot also about the agent tech experience. So, but we can talk more about that later maybe, but for the developer experience, to me, it's a lot about the development ruling. So having the right, I mean, shouldn't be specific to an editor, should be able, ideally, to use any editor, your editor of preference, but maybe the framework decisions have been made, for example, for the web application framework, but also for the testing framework, the testing runner, the built tool chain, the bundler, the development server, the storybook, for example, set up for your reusable front end components when you're building front end like me. And maybe even, so I'm a big fan of NX and one of the things you can do there is you can set up a project you can add tags. So you can add any metadata per project. And then based on that, you can make architectural boundaries, which is really important in a large code base. So you can say this type of project can only depend on that type of projects of the classical N tier architecture, for example, with database extraction layer at the bottom and business logic, and then maybe UI top. So you can make enforcement of that through lint rules added by NX when you add your own metadata per project. I think that's really nice for waking in a large code base. That's one example. And the other one is, so maybe you have a special naming convention for your large code base. But you can't, it's so complicated that you can even remember all the details yourself or anyone on the team. So then you make and what's called an NX generator, which can scaffold projects or front end components or services or whatever that follow that naming convention to the dot. And then of course, you add a lint rule on top of that so that no matter whether it was generated by the NX generator or by an AI agent or by a human handwriting it or copy and pasting it or maybe it got stale from an old branch, then the lint will catch it and say, oh, you're not following the naming convention. You should use this format instead. So having a lot of CI checks like that, that you can run locally and it goes into the CI pipelines. That's one example of a good developer experience to me. And then taking it to another extreme is what you mentioned in the beginning, continuous delivery and continuous deployments. I don't know how familiar you are with those terms, what you've done in that area yourself. I use the tools for it. Yeah. It's, yeah, I like it. Especially I'm more the tool guy. So I like to be guided from item well from DevOps, the git on it, so on. And I get my steps because I'm what a real corner. I'm more an architect. And so I speak to the people. They have more experience like you. But you've used GitOps as well. I heard you mentioned GitOps. What was that like? It's worse. I really fear I'm a deaf-optist guy. I hate it for the start, but I love all these kind of automation and versioning. And it's worse. I don't know. I think I use both to know together because I have my my my my boards. I have my my clear overview about my GitOps. It's so good. I think, yes, how was it? First, I feel very bad because as I started, deaf-optists don't have this integration. And I hate it. I don't use it. I say, no, no, no, no. But now I think it's, yeah, it's worked for me. Yeah, I think it's feels, I'm not perfect, but good. So yeah, so you've used, I don't know if I confused what you said, did you say GitHub or GitOps? The GitHub. Oh, I thought you said GitOps. Oh, because that's more bleeding edge, even more than continuous delivery, continuous deployment. I mean, they can be combined, but have you heard about GitOps? No, no. So similar to DevOps, but Git instead of DevOps, so GitOps. So that's a way of managing your environments and deployments and releases in a Git repo. Sometimes the same repo, and some infrastructure folder, sometimes in a separate repo. And then there are a lot of tool chains that can, yeah, that solves all the problems that come with that. Because I used it for a project, and we sort of build our own with some existing tool chains, but then we built some custom GitHub workflows and actions on top of that to make it work so that we could have a MOLSI repo system where we could have one of these GitOps environment reposts that could connect with all the other repo so that you could, for example, open a pull request and then an entire Kubernetes cluster with real databases and all of that was set up just for your one pull request with a preview or testing environment so that you could see it in a production-like environment. Of course, it wasn't to the scale of our production systems, but it was a real environment, was running on real Kubernetes cluster, was spinning up all the real containers and so on, just on slightly worse hardware, not production servers. But that was so incredible to see that and use that, but I also know that it took four months for the team to build that, and in those four months we didn't build any features. So, and of course, you always know the balance of make features or improve the development experience or the deployments, the workflows, or whatever. That's always the, what, which one do you choose? Yeah, there are some cool things we'll talk about. Let's take the NX stuff a little bit later. You say monoreps or large monoreps. I'm more working because my brain works, so I'm more than multi-independent respiratory guy. What, why should organization adapt monorep or what is the monorep and why should organization adapt this? So, and monorepo is using one Git repo or whatever version control system you're using and having all your systems in that shared repo, that shared Git repo. So, monorepo, well, you can have multiple systems and they can all be deployed from that single repo. So, even if you have a microservice architecture or micro-frontends, they can still share the same repo and be independently deployed. And that's one confusion that some people a misconception they get that if you have microservices or micro-frontends, they have to be in different repos. No, that's not the case. It's more matter of organizing the folders and maybe using some tooling like NX or Turbo repo, Rush or Learner base. There's a bunch of them. So, yeah, so that's a monorepo, having multiple projects or multiple systems in the same Git repo. And when you have that, then you have to either make some custom scripts or find some working, some tool change that can help you with that. And yeah, it's just a big, I love monorepos, but I also have seen in huge systems that it's with hundreds or thousands of developers. It's not easy to get them into one repo because they already have dozens or hundreds of repos in dozens or hundreds of teams and hundreds or thousands of developers. So, getting them into one repo is really hard, unless you did it from the beginning and you kept onto having just this one monorepo. I mean, Google, Microsoft has, Google has one monorepo for all their internal systems. They have some open source repos. Of course, they are in separate repos, like Angle has a few repos, for example, but they are actually synced, every commit is synced into the Google monorepo. So, they use their commit from their open source repo in their internal monorepo in Google, as an example, Microsoft has not one monorepo, but a few, for example, one for office, one for windows, and so on. Okay. Yeah, I think for my understanding, how did we, when we have one, it's called it all be, I think it's also hard, not thousands of the developers, but hundreds or 10 of the developers, it's called be complicated. How can we handle this, that we get a result? And then, I think when I have all the monorepo, then one due to makes an epic failure, and nothing, nothing runs again, I use the, yeah, and you're touching on something important here. It's usually not the tooling, the developer experience, or the development tool, that's the problem. It's usually people, people having to interact with each other and manage their dependencies between the teams, and whether you're in multiple repos or in a monorepo in a shared code base, there will be problems. And, and going into separate repos doesn't solve the problems. It just manages them in another way, because now, you can't, another team can't contribute to your code, so they have to talk to you and make change requests. Can you change this? I depend on that. And so on. Okay, so how do we test that in your repo? We're in separate repos. Now we have to spin up an environment that apply both our code bases and see if it breaks. Whereas in a monorepo, you can usually run the multiple systems, even locally, or more easily added to a pre-u environment, because you have all the code available in just one repo. But as I said before, it's not, it's not easy to move many, many developers into one repo, especially not if they already have many repos. So something new that came in this area is actually, as I mentioned, from the NXT. NXT has always been a monorepo toolchain, but they have also seen with all these Fortune 500 companies and big enterprises that it's near, near to impossible to get many, many repos, many, many developers. You get them into a monorepo. It can be done, but even that process is just it's long and hard and you need experts and you need a bunch of tooling to make it work. So what they have done is that the next is they have released a new product called Polygraph. And that is related to AI in that it's also a meta harness. So it helps your AI coding agent set up or manage multiple repos that have dependencies between each other. So you can manage multiple Git repos in a single session and you can say I want to change this, then I want to change it both in the backend repo and the front end repo and this first service repo and so on, microservice repo. And it can do all of that. It can run it on your machine. I can see how the dependencies go. NX has this concept of a project graph where you can see how the projects are interconnected. That used to be in the same code base. Now you get something similar in a poly repo set up. So now that's why it's the polygraph because it's the graph for poly repos. So you can see how they're connected even though they're not sharing the same code base or the same same Git repo. And then it can make your AI coding aided understand that better and it has some session recording so that it's you can sort of backs up or logs the sessions you have with your AI coding agent and then you can share it with another developer on your team and say can you can you continue this session. Here's the whatever key and they could jump in in their AI coding agent, open up polygraph and say resume this session and now they're continuing your session from your machine on their own machine and they still have they still have this so maybe for this one session these two repos or these three repos I set up because they are relevant to the change you're making. So now it's like having the environment set up for for the AI. So you already did it just by configuring polygraph and now you're sharing it with your colleague. Here's the here's the harness for for this change and then you can use that to get it to open multiple pull requests in multiple repos on GitHub for example. And then then manage that dependency through the AI coding agent. What do you think about that? I have so so so many questions about monoreps but let me a little bit unfair and I'm a little bit out of this topic. I see some guys have an X and stand on their LinkedIn profile. I never never before heard before we have say we make make this podcast. I have googling or as Tetris BT a little bit about an X and I don't know really understand what an X is is an X and building system is it a frame where for monoreps or is it a developer platform? What is an X? Everything you just said. It has some it has multiple features it has grown over years and the product I mentioned before polygraph that's a separate product but also from the NX company. They used to be called novel technologies and they're still legally called that then they switched their name to NX and the company as well because NX was their primary product most of it was was and is open source and then there are some premium features on top of that they're called NX Cloud and things like that. So but polygraph is something separate it's a separate product it doesn't require NX there's basically not even an NX integration polygraph yet I'm sure it will come later on that's a natural fit for these two technologies but just to be clear that polygraph is separate you don't need NX to use polygraph if you work in multiple repos whether it's open source or in our source or just a big big company many developers many repos then and you use AI coding agents then polygraph is is a pretty sweet product and right now everything's free because it's it's early stages so you can you just submit a form and then you you get access to to use it and use all the features for free for now so and there's no you don't have to add anything to the repos to use it it's it's driven via their cloud servers of course if if you are in a company you might need to have them have them vetted as a vendor they have typed to stock to compliance and certifications and all of that so but you might have to go through that vetting process if you're in an enterprise but of course that's possible both with NX and polygraph then circling back to what is NX well it it used to be mostly about javascript code places whether that's notice bagans or angular react frontens or whatever and it was about picking a few technologies not just one of each but a few for example react and angular has official integrations in an NX and then testing wise there's just karma and vtest and vtest browser so and then so in javascript there's so many tools and they change all the time so it's hard to figure out how to set all of that up so basically that's the biggest or that used to be the the big benefit of NX that it can integrate all these tools together and when new versions arrive NX will have configuration or code migrations that run automatically no matter how many projects you have it will upgrade all the projects in your entire code base with the configurations for each of these tool chains like testing and linting and and building and and compilation all of that so that it was just again something that that's part of a good developer experience is not having to worry about how you set up all those different tools and and how they integrate together so that's something NX did for you and then on top on top of that it has these generators as I said where you can scaffold components or configurations or tests or whatever and you can make your own and it has what's called the executors which are rappers for different tools so there was an executor for eos lint there was one for just testing and so on so basically all your CLI commands had what's called an executor in NX which meant that NX could run them for you across all even across hundreds of projects it could run all of them so all the tests for example whether it's with locally on CI and you can filter the projects based on these metadata project tags and so on today though you don't need this special context of a concept of it and an executor anymore NX will also detect the tools you have the configurations you have so it's more of a Cyril config or close to Cyril config tool chain now whereas before you had to have all these different NX specific things like the executors but now it's inferred based on the configuration files and dependencies that are already in your project and then adding on top of that is not only about java script anymore there's now official support for .net and java, maven and gradle and things like that in NX itself and then on top of that there's open source projects for other supporting other programming languages like iphone and go things like that so it's at this point it's a what's it called a polyglot tool chain for task orchestration and integration of tools and then on top of that comes the one of the premium features which is caching so all the commands that you run locally on your CI server like build test lent format all of that is can be cached both the files they would produce and the terminal output they would produce so if you run tests unit test or n20 test for your big project in your code base and it takes several minutes as an example for n20 tests then if the files the test files and the source code files it touches doesn't change and you run the same command again you get the immediate cached output of that oh the test is still passing no wonder there was not any code change but at the same time maybe there was some code change but it was in a separate project that wasn't there was no dependencies between the projects in your code is even down there when sync code base nx was intelligent in that they could see there's no imports between the projects for example there's no dependencies between the projects so we know that this this task is will get the give the same outcome short of flakiness and test for example but but in ideal circumstance it should give the same output especially for unit test instead of n20 test and for linked tasks add to on top of that distributed caching or remote caching so now you can share these cache task task between your team and the CI server or maybe just one way maybe only the CI server can write these cache entries and then you get to reuse them on your local machine so if and usually all the the projects have been tested for the latest commit on a branch or in the PR on the CI server because someone pushed it so that when you go and open the project on that branch you can get the cached output in milliseconds instead of minutes or hours for running, testing and linting and building and compilation on top of millions or hundreds of thousands of lines of codes and hundreds of projects so yeah that's that's some of the basic features of nx and then comes a a i things on top of that so that that was the crash course in nx and the most basic features for me for understanding how did nx fit into the the the get up I say get up world from your experience is it um well um in the get up well will which which part of get up I I think about something specific or open source or yeah open source um this is there is I don't know I understand it's it's and exist it's the basic it's completely free uh normal open source yeah open source normally open source companies tell you I don't know uh business extensions or they sell you consultants or they sell you yeah I don't know so obviously it's stuff they sell you some add it on slide like the caching uh yeah um what what did you think um and I think get up it's hyper-microsoft I don't know I think so uh uh let me uh think about my question uh um uh so well all all the features I just mentioned are free and open source in nx and then comes on top of that nx cloud and and all the features that are in nx cloud we I I talked about the caching there used to be free solutions for self hosting the cache remotely for example in in an amazon s3 bucket or asher blob storage or google cloud storage that's no longer supported out of the box but it can build your own integration there's an open API spec if you want to host your own cache server so it's doable but it's not plug in play out of the box anymore so if you want to remote caching uh you you'll have to pay for nx cloud basically um and then uh yeah just to mention one thing you how does it fit with open source will open source projects can get nx cloud for free so they get all the paid features for free if you're an open source project fill out a form they approve you say here you go here's your license key uh there's a pretty well-known uh family of projects in the javascript ecosystem called tan stack and that's uh at this point a huge code page based with many packages going into npm many developers many different contributors that that uh maintain each of the packages and they have because of that they have a lot of ci running in github um and then they use the nx cloud so they get all this caching for free which means they're developers they're open source developers uh have to spend less time waiting for ci because it's cached in the nx cloud and then of on top of that there are some features like you can go in and trace how how much did each step of the ci work flow take and how can you optimize and get some ai assistance into optimizing your ci pipelines and even if there isn't an error something that fails in ci you can use what they call ai autofix so the ai will make a suggestion on how to fix the failing ci task and open a pull request to fix that part of nx cloud also as an example when you have the paid nx cloud subscription or your open source project that get the free open source license so it's more um competition to to to github co pilot uh not github co pilot uh but github actions github as a ci runner uh it is a competitor because they have what they call nx agents and this was before ai coding agents became a popular thing so maybe the name is not so good now but it's not like agents hasn't been used a thousand times before for different things in software uh but basically nx agents is they have ci runners and uh to but to use them you still have to have your github actions work flow yet you have to start one runner in github and then everything else is delegated to their ci cloud uh in nx so you just have one job that you start and then it'll delegate tasks and say okay I need to build these projects I need to link these projects and then it'll connect to the nx cloud and they will run all those tasks in their ci system which is optimized for speed and caching and all of that and you will get the result back into your github action stream which means you have one job and that'll be delegated all the different tasks to to the cloud and setting up that pipeline is pretty easy you basically tell it I run I want to run run build a lint test and then it figures out how to delegate that to the cloud so so configuring a workflow in github to use nx cloud nx agents is pretty easy and there's even a generator for scaffolding that workflow even works for different providers like github and circle ci and few others okay uh bar this was so much information my brain takes uh the leads the leads in break um okay um I think well it's yeah yeah you you asked is it a competitor to co-pilot uh well the the closest thing there is yes the AI autofix that's also something you can get from claw or from co-pilot or you can set it up pretty easily or you can get it from i don't know co-crab it maybe so yeah there are there are lots of competitors in this scene of something broken ci uh AI give me a pull request to fix or make a commit to fix it right so in that sense yes they are competing co-pilot uh for that that thing but they're not in a local AI coding agent but the polygraph product I told you about is a meta harness for any AI coding agent so whether using github co-pilot or cloud code or codex or jemeni or whatever uh then this polygraph can sit on top of that and help your AI coding agent set up these different repos uh lock your sessions um and uh give them some agent skills to how to manage these different repos and how to open pull request for for multiple repos and so on and uh of course how to navigate between the code in multiple repos within one session usually you have to open up the coding agent in one repo and you cannot reach the code outside of that repo that becomes the sandbox that becomes what your agent is allowed to see and change but with polygraph now you can work in multiple repos with one AI coding agent session yeah awesome awesome i think i think a little bit about it normally i love the theory but uh let's make it more practical uh that's an organization they have a large uh anics mono repo they have 500 employees or five-front developers typescript applications front and back and service hundreds of libraries github github actions playwright Ezra strict architecture rules years of legends code and github code for full pilot and the leadership says to you we want agent to handle 30% or 50% of routine development work and in the next i don't know next three months what what will you say uh well i will say uh it's a good it's good that you have all these tools because that's easy for an AI coding agent to use they already know anx the tool chain they know how to read the architectural boundaries they know how to use the anx tasks and the caching um because that's pre-trained knowledge to the models they know all the popular open source and paid tools otherwise they wouldn't be very good if they had to learn a new tool every time you open up a session so good thing you already have anx and modern tooling about your legacy code base that's less of a worry because uh of course your coding agent can't be pre-trained on that uh to do that you would have to fine tune a model for your specific code base which doesn't really make a lot of sense in most cases maybe except if you're google or Microsoft with these giant jantic uh monitor repose for windows and office and everything internal in google um but instead what we can do today of course is develop our own agent skills for our own code bases so uh something about how does your team do this and that there's always something that's specific to your team or your code base that can now be codified into agent skills and agents.md instructions no matter whether you use and copilot or clock code or something like that so and then the if you say you want them to take to you to perform or execute 70% of routine tasks that's definitely doable you say routine tasks i mean what is there something specific you have in mind? at the end of the day it's a matter of do you want to pay for that? Using AI coding agents on a schedule is not cheap if you have to pay per token and you run automated tasks every day so for example if you have an agent that goes and takes maintenance tickets and say you're using github someone opens a maintenance ticket you need to upgrade your .net framework or your angular framework to new version and then you want an agent to take that ticket and do it for you that that's possible but you have to pay for each token spent and that's that's not cheap but if you compare it to having a developer that does all these maintenance tasks every day or every week or every month then of course there's there's a financial puzzle that that might make sense and add on top of that that maintenance is not really for most developers the most satisfying part of the job and that's part of why it gets done too rarely but also because it's not something that gets prioritized in a product roadmap there's not an entry in the product roadmap that says update to .net 10 know that that's something the team usually have to take care of using their own policy but then comes to protocol and says no but we have to build this feature okay I guess we'll post to post-pone that .net 10 migration for another year more oh oh this was so many so many information let jump at the end of the podcast in the rapid fire round so I give a short sentence and you give a short answer so GitHub actions are another CI system they are the best CI system GitHub Action question. Playwright or suppress? Playwright. ...co-pilot chat or autoparbij? Coupilot chat? Do you mean co-pilot agents? - Yeah, yep... I mean, I actually have... I have a quote on the co-pilot extension product page where I say that I will never code without co-pilot again because it works so well. It works shockingly well or something like that. That's a few years old and as I said, I was a very early user of co-pilot because I was a GitHub star. I got early access. I gave early feedback and so on. Now, I rarely write any code by hand. I'm... I instruct... and I've been doing that for... in open source for more than a year, professionally since November, December. I have barely written a line of code by hand. So the agents do all the work. Whether it's co-pilot or co-pilot, they're so good that... that's possible. It's more about how do you review and ensure the quality of the code produced by the agent, right? So sorry, what was the question? I lost the thread here. It's a rapid fire rinds, so next turn, it's Karlsbach or Trubork. Human review or automatic verification? Okay. Okay. The most underrated type script feature. Underrated type script feature. I don't know. I'm more a fan of JavaScript itself and it has all the features you need. You don't need type script at the end of the day. Yeah, so yeah, then you lost your war. That was... was... oh god. I... I... next time I have to do more research before I do the podcast. Yeah, but for me, it stands out in the conversion with... it's... how the... yeah, how... architecture, yeah, it's changed from... from the development. It's... so... I don't can... I don't can bring it in my brain because it's so interesting. Yeah, normally I ask... who is the negus guest I should invite? It works the secret question, but as I have you asked another question, I'm not the divana-pagai, but I meet one for the podcast. So if you like, you can become a host. You're really welcome. And I think this was so amazing. It was... yeah, it was really amazing. And for the guests, all the information about last are in the show notes. And yeah, thank you. Thank you so much. This was... whoa, it was overwhelming for me. Well, hopefully your listeners got some inspiration as well. They're free to reach out to me. Find me on LinkedIn, contact me there, for example, or find my email addresses and my GitHub profile. And if I were to suggest a guest for you, you should talk to my friend, Santo Shiyada, who is also an open source maintainer, and now he works at CodeRabbit. So there's a lot of interesting stuff there as well in terms of DevOps and AI and the combination of those two things. Yeah, then thank you last for staying here with me this hour and yeah, it was amazing. I learned a lot and I have a lot research to do. Thank you so much for staying with me. You're welcome.