BrandGhost
All videos

Rider x Air x Junie: Will AI Fix My Mess?

In this video, we check out Rider x Air x Junie in a practical setup where multiple agent sessions help us fix some errors and redesign some UI elements.
View Transcript
what it looks like. We'll start with the activitywide list. Boom. We have these new badges that are nice and bright. Today, we're going to be looking at using air inside of Ryder. And I'm going to try out Juny as well. And we're going to put it to the task of working through a bit of a UI redesign in an application I have. And I noticed there's some weird things going on that I need to have another agent investigate. So, what I'm going to do is flip over to a couple of UI screens that I have that look pretty crummy in my opinion. I have a couple of other ones that we've mocked up and then I'm going to see if we can get things going. So, let's jump over to this view here. You can see that this is a narrow view of one of my UIs that I have. So, this is in a database management tool. And I don't mind the very top, but the rest of the screen is pretty crowded. The text is just very noisy. If we go to the other variant of this, this is what it looks like on a wider screen. Again, I'm okay with the top part. The left nav is okay, but there's just a lot going on on the screen. So, I have a couple of other AI generated mockups that try to help clean this up a little bit. This screen in particular is basically just the desktop view and the the mobile view or narrow screen view together. And then if I jump over to these other two, really what's going on here is that there's a little bit more color and pop on some of the things so that you're not losing information in sort of the rest of the noise, right? So we're able to kind of minimize the amount of text, draw some attention to some things going on. If I jump over to this screen as well, just the same kind of thing, right? So these two things are really just variants of the same concept. So the idea in a nutshell is that these aren't perfect screens, but I think that these are going to be an improvement if we can put them in front of an agent and say, "Hey, can you look at the differences here and then can we try to work together to come up with something better?" So not just, hey, put this AI generated mockup rate in the in the product. I I want to kind of talk through it and see what we can make sense of. So we're going to do that. And I'm going to start by going over to my rider IDE. I have air set up. We can access air by going over to this A icon pulling up the agent sessions and I have a couple that I've done before. Thought it was pretty cool that it pulled in my co-pilot sessions, but I can just click new session. And since I was going to use Juny for this, right, I can select Juny. And that's actually what we have on the center of the screen right now. But before we check that out, just a quick thanks to this video sponsor, which is Jetrains. Now, Jet Brains has sponsored this video, but all of the opinions in this video are mine. This is a real scenario working through some agentic workflows. This is a real piece of software that I have that I'm working on. And so, I thought this would be a great fun opportunity to be able to showcase air inside of Ryder and Juny as well. So, thanks for watching and thanks to Jet Brains for sponsoring. So, what I want to do is start with our first agent. I'm going to say I would like to work on a UI redesign redesign. I have several screenshots I will will share of the product currently and I'm going to start by saying that um and then I will share some ideas for improvements after um and then I would also like your feedback on what can be improved and then so what I'm going to do now is add in these screenshots. So, we'll have this one here and then I'm going to add in the other screenshot. So, these two that are going in right now are just the first two images I showed of the narrow and I should mention it. Um, so the first screenshot is narrow and the other is wider view. So, I'm going to start that off and it's brewing. So, we're going to see what it comes back and says. But the other thing, I'm going to start another session here while that one's going. And I noticed that when I open this up in writer, I had a bunch of issues here. And so I have some weird thing going on here. I was not expecting to see this. So I'm just going to take all this text and say I notice that I seem to have some tunit problems in my IDE. Could you help investigate these? And I don't know why, this is my personal preference. I always like putting stuff that I'm copying and pasting that's not my prompt into some type of block. So, I'm going to go send that. And again, this is just another Juny session. So, I'm going to collapse the problems so that we get a little bit of screen real estate back. And you can see now that I have these two agents going. Can open this one up here. So this one that we started originally saying I'm exploring the source directory to map the UI architecture. I think that's a great start personally. Um and then if we go back to this one right I'm locating the project. Understand I found 70 unitit nullability errors across six test files. So these are both going. I suspect that the tunit one will probably be a little bit quicker to go through. But I'm really curious to say what this agent is going to say about redesigning my UI. I have not shared with it yet the other mockups that have some improvements because I also want to see what it has to say. All right, so Juny has finished up in this part of the UI redesign the first pass. So based on reviewing the screenshots, uh here's my analysis. Okay. And so what I generally like to do is kind of do a quick scroll through to see the top level things. So card layout. So there's text truncation, information density. I think this is going to be one that's really important cuz I think that's my biggest complaint. There's just too much, right? Retention section, destructive action prominence. Ah, so calling attention is something that is destructive. Paging controls. I think that's another thing when you have too much information. And then collection toolbar. Okay. So then has some suggestions there. Narrow view experience. So this is interesting as well. The sidebar is collapsed. Okay. I think that can make a lot of sense when it's narrow. Um, and then empty states and help text overall visual consistency. There's a lot of actual feedback here that I think is great. The design system in this design MD defines cohesive palette. Okay, I think that's good. That's it's good that it found that. I think that's important if we're going to redesign anything. And the current UI follows as well. But there are opportunities to use this color palette more intentionally. Ah, okay. I think that's really good because when we're building with agents, it's not deterministic, right? So I can have a design MD file. I can have instructions that say please follow this. But it's not going to be perfectly deterministic. We can do things like try to enforce these patterns different ways. But at the end of the day when we have agents building things, there are going to be these opportunities where it's not perfect. Okay. So while this has popped up just to do a quick check on the other one, right, the T-Unit one. So it's actually going and fixing, which is super cool. I didn't actually ask it to do that. I was just kind of curious about it, right? So, we'll let that keep going. I was wrong. I thought the T-Unit one was just going to answer right away, but um I am going to share a couple of visual mockups that might help with improving things. We don't have to use them as a uh exact destination, but they may give you some ideas. Then we can discuss the action plan. So, I like doing this kind of thing where I'm doing a bit of brainstorming back and forth with the agent. um then it's not just a straight let's vibe it, close our eyes, cross our fingers, and hope that we get something in the end. I like doing a bit of back and forth. So, I'm just going to paste in the other screens that I've already shown you. So, I'll get these dropped in here. Right. So, get those going. We'll check in on TUnit here. So, still going and fixing things. Is actually doing the builds here. So, let me actually read this now. Found the actual file policy. The error message has placeholder prefixes. Okay, I've identified the root cause. Oh, it updated the whole message for me right when I was about to read it. Um, but that's cool. It actually fixed it, right? So, fix seven uh tunit nullability errors across six test files caused by is not equal to and and assert that expecting nullable reference types. So, that's super cool. All three affected test projects built successfully, zero errors. Um, so I'm curious, right? Like did this change any behavior or is it the same idea for behavior but we have structured the code properly. So I'll let that run. I can see over here right the other session says the redesign UI needs input. Okay, cool. So now we have a bit of a selection here. So, enter planning mode. Based on the visual mockups you shared, I can see the three main improvement areas. Which aspects would you like to prioritize? Right. The time uh time stamp, formatting, outcome, color coding. Um I think honestly the card layout like can I do? Oh, I can I can pick one. So, I had maybe a couple that I'd like to pick, but I think overall the idea is that if I can start with one, it's software. we can iterate. So, um I think between color coding and the card layout, I think those are my top two. So, I've chosen to prioritize color coding. Um so, then we get this plan, right? So, let me see. Show more overview. Add visual color coding activity record completion status. Okay. Proposed change implementation. So, we know that it's going to modify this specific activity page, which is you might not be familiar with it, but that's going to be the page that we're actually touching that I shared screenshots of. So that makes sense to me. We're going to get this proposed change here. So create completion badge component. Okay. Update the record. Add CSS classes. Great. So one thing that I'm going to ask it because I see add CSS classes to activity.css. Um can I uh I don't want to implement it yet. I want to ask something. Um for the styling you are proposing should that live in activity or should it live in a central or shared spot um i.e. is this bespoke or is it part our UX architecture. So, the reason I'm asking this is because what I don't want to have happen is that if we have something that genuinely should be shared across the service of the application, I would prefer if it goes into a common reusable spot. Of course, if this is something where this screen has something that is pretty unique that we're not reusing, um I think it's totally fine to live directly on this screen. And maybe in the future if we're going to have sort of uh another situation that might want this, maybe at that point we can go refactor it. But I just wanted to ask it, right? So uh where should the completion badging styling live? Good question. Based on the project's existing CSS architecture, the completion badge should live in app.css, not Okay, so I'm glad I asked, but it also explains why the project already has an established pattern for badgelike status indicators. Okay, great. So there's actually some badges that exist already. All of these share the same design DNA. So there's a pill shape micro topography color-coded border design tokens. Okay. Proposed approach added the completion badge to that same spot. Keep completion badge or react component in line. Right? So the component itself is going to be in line. Um and then it also says or extract it if it's going to become widely used. I think that makes sense at the point where we're going to reuse it. if that's ever going to happen, then we can pull it out. But the shared styling in one spot, personally, I found that um I get more consistency in my UIs when I do this kind of thing. So, let's just double check this plan. So, it's going to seemingly do the same thing. It's going to modify that page, but add the CSS classes in. Uh so, it says the same thing here. So, add CSS classes and activities for badge styling. Um, so I'm going to tell it again because it seems like it's saying the same thing. So, the plan still says this. Oops, I can't type properly. There we go. Um, shouldn't it be in the appcs file? We'll just see. Maybe the plan was stale. It's possible. I didn't actually read but it might have edited the file and it's displaying a previous one. So let's just double check. You're right. Okay, cool. Now you can see it's editing it. So once again we'll double check. This is why we always check our work. Uh now you can see add CSS classes in app CSS. Okay, I'm going to approve this plan. Confirm and implement. And this thing is going to be off to the races. Now, I didn't ask it, but I want to make sure that when it's done, um, we'll see if it can either launch it for us to look at and or if it's able to do some type of rendering. Uh, my preference is that I don't want to have to go launch the entire app to get to this screen. Depending on the apps that I'm working with, maybe that's actually a shortcut. In some cases, it might just be way easier for it to do a a mockup rendering for us. So, it kind of fakes getting through the app, but still renders the components. Let's go check tun again. What did it answer for us? So good. There is no behavior change. I'm jumping around a lot, but I'm demonstrating this because this is actually generally how I work when I'm going between uh not just two sessions, but sometimes across projects and multiple sessions. So, it's a lot of context switching. I realize that might be a little confusing in a video, but this is sort of how I I operate personally. So, no behavior change for the TUNT fixes. They express the same runtime assertions just structured to satisfy the nullable reference type system and then it goes and explains it. So changes 1 to four is not equal to got changed to is not null and is not equal to. So then it lists the files the same behavior because the value being asserted these things here are string that's nullable. The old code already assumed these were non-null at runtime. Okay, good. The test would have failed with a null reference or incorrect assertion if they were null. The is not null and chain just makes implicit assumption explicit. Okay, I think that's great. I'm glad that there is uh something that was surfacing that. It was probably like a Roslin analyzer that was going. So, I'm glad that we had that and I'm glad that this fixed it um trivially and I could ask it in simple terms, right? Like it was great. I probably could have done a little bit of poking and proddding to make sure based on the change, which if I click, we can actually see the diff, which is awesome, right? So, we can literally go check it out. However, if we were not familiar with this, so if you're not familiar with Tunit and what this is doing, or if you're not familiar with nullable reference types and things like that, the sort of the the question mark uh is it on my screen? No, it's not. But when the type is appended with a question mark, right, if you're not familiar with how those things work and you see that it just made this change like, hey, great, the problem went away. Sure, the, you know, the problem in your ID IDE went away, but does that mean the problem's actually gone or do you have a new problem? Right? So, uh, the fact that we can, you know, get this explanation in simple terms, at least in the way that I personally understand this, um, I think that's super helpful. Again, depending on the context, if you didn't understand it, I think it's great. You can just sit here and iterate and say, uh, can you explain, uh, let's see, um, change five in a, so I didn't actually read change five, but I'm just using this as an example. Like, if we if we did not get this, right? So, it's explaining it and you're like, I don't really I still don't really get if that's actually safe or not, then you can just ask it to explain in a different way. So that's great. Let's check in on the UI redesign. Still going here. So added visual color coding. Talking about where the changes are so far. So if we're checking in on this, I think this is a great start because it matches what I saw in the plan. Right. It's going to touch activity page tsx. It's going to touch app.css, which is a good sanity check for us because that was something in the plan we went back and we altered. So good to see that it's touching the right spot. verification. So, TypeScript compilation passes for the modified files. Great. Uh, in SQL editor tsx unrelated to these changes. Oh, so the only error is pre-existing missing code mirror search. Ah, I missed that part. So, interesting. We'll see if it's able to compile. Uh, well, actually, I'm kind of curious. Maybe it's going to say something along the way that it tries and fixes this. Otherwise, it might say, and I don't actually expect it to necessarily go fix this. It might tell us, hey, look, this is still an issue, but it's pre-existing. That's fine. I still want to see if we can get some renders of it. Otherwise, we might see that it actually goes and fixes it. So, I'm going to let this continue to run and I'll resume in a moment. I think I was actually being silly and it was already done when I came back here. I thought that it was it was still computing. So, I had paused and then I went to check back and resume, but I'm like, wait a second, it's already done. So, um, are we able to get a visual render of the screen now? So, I'd like to see if we can get Oh, so demo isn't available with Juny Light. Okay. So, let's see if we can switch. Um, can I go to I'm going to use a different feature here. So, I was using Juny the light version uh which is really great to try out because it's free and I thought that was really cool. Uh, I also have co-pilot as well. So, if demo is not available in Juny, totally cool. Let me jump over to Copilot. I'm going to have to log in. So, I'm going to come back in just a moment. Awesome. So, this was probably the easiest setup I've ever seen for connecting uh a harness into something. Uh I got very nervous because having to go jump over to another provider in the middle of this. I uh was like, "Oh, maybe this would have been very good to go spend a lot of time up front preparing and getting this all working." Uh but turns out we can just do it on the fly and it works pretty easy. Uh can you see the contents of this Juni session? Um, we were working on a EY. So, I think it's really cool that Juny got us all the way here. Um, we're going to see if it actually got the the color coding implemented. So, I just want to see if it can see the session. We'll say always allow. And I'm curious cuz now we're using one harness to check the session of another. I don't know if I can use I can't use YOLO in here. Um, I probably have to do some permission tuning. So, I'll stick around and click the the permissions. When I'm using co-pilot, generally I'm in YOLO mode, so I can walk away, but this is totally fine. Can actually pay attention to what it's doing, right? So, yes, I can read the session. It contains your activity. Cool. Um, are you able to use code changes that it produced to get us a visual render that new UI so we'll see again it's calling out right that it has uh report adding color coded blah blah blah and then it mentioned the compilation blocked right I'll check Jinny's changes I think this is a a really fun use case that we were able to use one harness reach a point uh and this is only because I'm using the the free version right so totally cool changes and then honestly adding the new harness was super simple like I haven't used clawed in here yet but all that I did was just clicked install like I have clawed uh CLI installed claude code installed on my computer already so just pressing install was I I mean, quite trivial. Um, yeah, I'm I'm kind of blown away that it was that easy. I didn't even have to I thought I was going to go through this awkward login process for authentication and it just just worked. Great to see. So, it's co-pilot just going and checking what's going on. Another uh probably important thing to mention, right, is that we are using like different harnesses inside of here. So, I would be curious. I haven't done the homework on this yet, but depending on what harnesses you're using, what skills and things are accessible to them, um it might be that you have a different experience, which may be uh like good or bad, right? So, I think if you're not if you're going to get a different experience, you're not expecting that, I think that would be bad. But if you have the ability to go between your your different providers, I think that's super cool that you're not locked into anything. Um, personally, like I I use both Claude and Copilot in my own personal project. So, uh, depending on what I'm doing, going between either gives me a bit more freedom and flexibility. So, the fact like if I'm in Ryder, I can use Juny. If I want, I can use C-Pilot for certain things. Um, I think that's that's awesome that we can. All right. So, Co-Pilot has finished up here. And I just wanted to make a quick note that when Copilot for me does these links where you can see this says wide cards, narrow cards, and wide list, and they're a hyperlink to a file. In my co-pilot sessions, these never seem to work. So, I always end up asking for full file paths. I'm not really sure why, but I noticed the same thing happened here in Ryder. So, I think it's just a weird co-pilot issue that I have. But, I do have the full file paths, and I have them opened up at the top. So, let's see what it looks like. We'll start with the activitywide list. Boom. We have these new badges that are nice and bright. Maybe I should move my own ahead so you can see what's going on there. Look how good that looks. That's nice and bright. And then this is the narrow view, right? So, we have these cards in this narrow view as well. Again, one of the optimizations we picked was to have these colorcoded badges stand out. Personally, I think that makes the information a lot easier to digest. I think there's still more that we can improve on here. That's totally fine. But we just use this to get one of the iterations done. And here's the other view, right? We have uh the wide view. And again, the badges are called out there. So overall, I'm pretty happy with this. I think that that was a really cool opportunity to have Ryder with Air work across a couple of different agent sessions. So, we were able to do a little bit of debugging and fixing for some T-Unit tests at the same time that we were doing a little bit of a UI refactor redesign with some source images, some back and forth on the planning. And then we were able to use the free Juny harness that we had. And then we could switch over from Juny over to C-Pilot in the same sort of rider session. I could tell co-pilot, hey, go check out this other Juny session. Continue on. We had the renders get put together and it was awesome. So, even hooking up co-pilot and I briefly showed going to Clawude Code to be able to install that. Super simple to do. I was a little bit nervous that maybe I was going to click it and be like, "Oh no, I'm going to have to go navigate this." But super easy. So, overall, I'm pretty impressed with this and I'm excited to use it more. So, thanks for watching and I will see you in the next video. Take care.

Frequently Asked Questions

Which tools did you use and how do you combine them to run an AI-assisted UI redesign in Ryder?

I use a combo of Ryder with Air, Juny for AI-assisted sessions, and I’ll sometimes bring in Copilot or Claude/Co-pilot as backups. I start in the Ryder IDE, open Air to spin up an AI session, and upload my narrow and wide UI screenshots. I ask Juny to review the designs, propose improvements, and we iterate with back-and-forth prompts. I also open a separate session to surface IDE issues (like tunit problems) and keep both conversations running in parallel, switching between them as needed. Finally, I check the AI’s plan, confirm the changes (like a new completion badge and CSS tweaks), and preview the results through renders when available.

Can AI fix code issues like TUnit nullability errors and ensure no behavior change?

Yes. In the workflow I demonstrated, the AI identifies the root cause of TUnit nullability issues, proposes precise code changes (for example converting certain assertions to isNotNull and updating related logic), and applies them. I then run the build and verify that TypeScript compilation passes and that there’s no behavioral change. The AI explains what changed and why, and if I’m unsure, I can ask it to explain the change in simpler terms or show the exact diff so I can confirm everything aligns with the intended behavior.

How do you get visual renders or previews of the UI changes if you can’t run the full app, and how do you switch harnesses if a render isn’t available?

When a full render isn’t feasible, I try to render via a harness inside Ryder. In the video I first attempted Juny Light, but it wasn’t available for a live render, so I switched to Copilot (installing a harness) to generate a visual preview. The process involves using the same session context across Juny and Copilot, checking if the updated UI (like color-coded badges in narrow and wide views) renders correctly, and using the diff and render outputs to validate the changes. If one harness can’t render, I switch to another (e.g., from Juny to Copilot) to get a preview without launching the entire app.

These FAQs were generated by AI from the video transcript.
An error has occurred. This application may no longer respond until reloaded. Reload