Claire Vo: Welcome back to How I AI. I'm Claire Vo, product leader and AI obsessive here on a mission to help you build better with these new tools. Today I have CJ Hess at 10X. And if you've seen him on X, he is building some of the most useful tools and flows for being a quote unquote real AI engineer. We're going to get a sneak peek in his tool Flowy that he viodated for himself and he's going to show us how he uses modelto-comparison to make sure his code is great. Let's get to it. This episode is brought to you by Orcus, the company behind Open-source Conductor, the platform powering complex workflows and process orchestration for modern enterprise apps and agentic workflows. Legacy business process automation tools are breaking down. Siloed lowode platforms, outdated process management systems, and disconnected API management tools weren't built for today's event-driven AI powered cloudnative world. Orcus changes that. With Orcus Conductor, you get a modern orchestration layer that scales with high reliability, supports both visual and code first development, and brings human, AI, and systems together in real time. It's not just about tasks. It's about orchestrating everything. APIs, microservices, data pipelines, human in the loop actions, and even autonomous agents. So build, test, and debug complex workflows with ease. add human approvals, automate back-end processes, and orchestrate agentic workflows at enterprise scale. All while maintaining enterprisegrade security, compliance, and observability. Whether you're modernizing legacy systems or scaling nextgen AIdriven apps, Orcus helps you go from idea to production fast. Orcus, orchestrate the future of work. Learn more and start building at orcus.io.

Claire Vo: CJ, welcome to How I AI.

CJ Hess: Thanks, Claire. It's good to be here.

Claire Vo: So, I've seen a lot of Claude and AI engineering power users, and I still think you're like a super power user of some of these tools. And it's not just because you're creating real production code with what you're building, which is really nice to see, and I think a subset of what we're seeing out of folks using these tools. You also build tools for yourself to make the process of AI engineering better and you share those tools with other people who then validate that they're actually helpful. So why are you so excited about in particular Claude Code and what has it changed for you as as we were talking before the show a quote unquote real software engineer?

CJ Hess: Like a lot of people the Opus 4.5 moment was a big one. But I've been on Claude Code, I don't know, maybe last May. But for me, it was really about the harness they have and like I see a lot of arguments about Codeex in Claude Code. And I'd honestly argue GPT 5.2 is a smarter model, but like working with Claude is just such a delight like in Claude Code. It just feels so like steerable. And I think the one thing it really has is like intent understanding. Maybe I'm not giving, you know, Opus and Cursor like the the shot it deserves here, but there's something about include code like when I wanted to dig deep, it just it just does it. It feels to like pick up on my intuition just in the prompts. And it's really enabled me to almost like build a little ecosystem of my own tools around it around Claude Code kind of particularly with skills now that just like keep making it better and better for me because it's Claude Code plus like this system of skills and tools that I've built around it. So it's it's like really hard for me to get out of it.

Claire Vo: Yeah. What I love about this moment as a software engineer is, you know, back in the in the olden days, you sort of had like your choice of like what's going to be my IDE and am I going to use Vim and like what, you know, what are my my set of approved tools as an engineer that I can use to make, you know, what llinters are we using as a team? All this kind of stuff. Like there's stuff that you could do to customize your developer environment. But now you can really take it to the next level and you could have a totally different AI engineering workflow than your colleague sitting next to you and it's totally fine because it's making you individually a lot more efficient and effective and you're building them yourselves for pretty cheap. So there's not that cost or that hurdle of evaluating new things in your stack.

CJ Hess: Yeah. There's even like it's almost like one you now have the brains of Claude to almost like do some dirty work on the dev tooling. Like I think you know pre any of kind of the newer gen models that just really can handle the agentic loop and you know sitting with like a broken llinter and just accepting it and having like ignore comments everywhere so that you know I just I just would give up and now it's like I feel like I can almost trust it to be like what's wrong with this config? My IDE isn't matching what's in the project. Okay, we have to resolve this and just kind of solving those like chore problems that I feel like previously just ended up being forever problems.

Claire Vo: Yeah. And for the non-engineers watching or listening right now, I think environment setup and developer setup is such an underappreciated use case. Yesterday, I onboarded a designer who had literally has kind of like sat out some of this AI stuff. It's literally not downloaded anything, used anything. And she's on Cursor, Claude Code, nodes running, Homebrews installed. And I was like, just ask

CJ Hess: Claude Code to do it. Say like, help me understand this repo and get my computer set up to run

Claire Vo: and it just and I said and then just tell it it can accept all tools and let it go and come back to your laptop later.

CJ Hess: And it's pretty great. I mean, we're really really spoiled right now. So, let's dive into some of your actual workflows. And one of the things that I know you really care about is effective planning and you've come up with a way that you do your planning that I think is pretty unique.

CJ Hess: Yeah. So there's kind of the classic plan. So I'm going to swap over to Cursor here. I have in this just like your classic plans folder just throwing plans in here. And I really love this format. I think a lot of people are kind of converging on this of like iterating on markdown, having one file where you're just like working through the plan, reviewing the plan, and by the end of that, you can almost feel confident just letting it write the code. But the one like piece that I hated that I found really valuable was these asy flowcharts. So, if you're just listening, it's all those like boxes and arrows that Claude draws and, you know, there's always the ones where this one actually looks pretty clean. Yeah, there's always this like misalignment of that edge character. I don't know why we haven't figured that out yet. But for things like UI mockups, things like, you know, flowcharts of how navigation's going to work, how a certain system is going to work, I really like this visual way to think about things, but I really hate staring at these asy like diagrams. even things kind of like Mermaid and everything just didn't feel exactly what I was going for. So, I've played around with this tool to basically give Claude these JSON files. And there's a whole set of skills I've built around this that Claude Code can use to write these out. And then these actually end up generating nice looking UI mockups. Not in super high fidelity or detail, but you know, I can kind of guide it the direction I need. And up here, these this white text might be a little hard to see. But basically, this is a flowchart on this tool, Flowy, and how it works.

Claire Vo: So for for the listeners, what I love about this is Flowy is a tool that you built. This isn't you're saying like, "Oh, I was playing with this tool." It's like, no, you built this tool. Yeah,

CJ Hess: for yourself. This was this was my first experiment with a Ralph loop. I'm still not certain how confident I am in them because I had to do a little bit of cleanup, but overall I will say this is kind of a dev tool that was almost 100% prompted.

Claire Vo: Yeah. And so what you said is, you know, I love plans. I love the idea and and I just have to take a minute again. I'm the oldest lady on the internet. So way back in in the day, two decades ago when I was first doing product management and web design, we did so many flowcharts, so many user journey charts and then so many wireframes and so many like lowfidelity mocks than highfidelity mocks. And what I love about what you're building is you're building the AI native version of that. That piece has not gone away for anybody. It hasn't gone away that you said like when you click this it goes to this and these are the steps and these are the branches and all that. And it hasn't gone a way that you have to look at designs and say, "Yeah, this is kind of what I want." But now you can have AI create them. And at first you had a create AI create them in markdown very very low fidelity. And I have to take a side journey that you know a year ago I was like extremely delighted that it was making ASKI markups and now it's just not good enough.

CJ Hess: Yeah.

Claire Vo: The shifting expectations on these models.

CJ Hess: Yeah. Exactly. And so you've taken these markdown markups that were useful and you said now make them really useful by building this sub application that can run them for you. And it's a combination of it seems like workflow diagrams and step-by-step mockups.

CJ Hess: Yeah. So there's kind of basically what I wanted was JSON file. It can render and it can have nodes and edges like any flowchart and then roughly be able to stack them, change the colors and get us, you know, something that looks like this where we have a couple different screens and we have these somewhere between a wireframe and a true mockup that just can help me point the model in the right direction. The other big thing for me was iterating on this. I'm not gonna go in that markdown file and try to like write new shapes and combine them. So for this, this is also an editor and as you edit it, all these changes save to that JSON file. So you can then point Claude back at it and say, "Hey, I know you did this, but actually let's say I want to step here and I'm going to bring this up and add some edges." And then you can be designing in here almost like you're in Figma or Excalidraw or something and then Claude can just read the file and that's like a more native way for it to understand what everything looks like.

Claire Vo: And you mentioned Mermaid diagrams and so I have this question which is one of the benefits of Mermaid diagrams is that's a syntax that these LLMs know well and can parse and actually reason about. Do you feel like have you created a skill where Claude Code can understand and read this JSON? like how did you train it to read your kind of proprietary dev tool and documentation?

CJ Hess: Yeah, so right now there's two main skills I use. There's a third one that's just an overview basically kind of the highle view of what the commands are, what a what a Flowy file would look like. And then I have one that's very specific about flowcharts and one that's about UI mockups. And to make these I basically sat with sat in the repo of the tool itself had a bunch of like explore sub aents going and then started to make the first UI mockups and the flowcharts and started to guided on okay you put these too close we need a rule about like spacing and how to think about spacing and just incrementally I've been building that up where if I'm working with this and something goes wrong almost an example here would be this white text on these, you know, pastel notes, kind of hard to read. I would essentially hop into the place where I have these skills, and say, "Here's what happened. Give me a suggestion on how to improve this skill so this doesn't happen again." And then iteratively just keep building that skill. And the first flowcharts this thing made were, you know, shapes stacked on top of each other. It didn't make any sense. But it's come a long way. not much without many changes to like the underlying app. It's really just been about like getting Claude to understand and know the skill. And I find that works better than something like Mermaid just because I really feel the power of building my own dev tools now. And that

CJ Hess: I I really don't want to hit the constraints of Mermaid, if that makes sense. I want to be able to say, "Okay, I want a new feature in Flowy. I'm going to build it. I'm going to update skills and I can be confident that Claude can actually work with that and understand the new feature."

Claire Vo: Yeah. One of the things that I've really observed in myself as a engineer is as more and more as I access more and more of my dev tools through like an MCP or config as code or any of these things, I start to realize it's very easy for me to extend what they've built and customize it to myself. And so I do think, you know, of all the places, DevTools a DevTools is an interesting one where one, your users are super cheap and two, they're capable of of forking what you've built and three, there's so much open- source that I really do think there's going to be this trend towards build. I used to be when I, you know, I ran these big product and engineering orgs, they used to ask me build versus buy and I was like, "Oh my god, please just buy it. Like, please just take my credit card and buy it and let's not waste our time." And now I've flipped to of course we should build this until we hit some constraint we should build it. And certainly individual engineers if something's useful you should just build something yourself at least for for V1.

CJ Hess: Yeah. It's almost not worth spending the extra money anymore. I mean I've seen I feel like I'm seeing this pattern on Twitter but it's everyone's posting some product some ridiculous pricing tier and saying someone please vibe code this. You know, I feel like that's happening all across SAS.

Claire Vo: Yeah. So, can you show us how you'd either create one of these Flowys, use one in your Claude Code, like how does this actually work?

CJ Hess: Yeah. So there's kind of basically what I wanted was JSON file. It can render and it can have nodes and edges like any flowchart and then roughly be able to stack them, change the colors and get us, you know, something that looks like this where we have a couple different screens and we have these somewhere between a wireframe and a true mockup that just can help me point the model in the right direction. The other big thing for me was iterating on this. I'm not gonna go in that markdown file and try to like write new shapes and combine them. So for this, this is also an editor and as you edit it, all these changes save to that JSON file. So you can then point Claude back at it and say, "Hey, I know you did this, but actually let's say I want to step here and I'm going to bring this up and add some edges." And then you can be designing in here almost like you're in Figma or Excalidraw or something and then Claude can just read the file and that's like a more native way for it to understand what everything looks like.

Claire Vo: And you mentioned Mermaid diagrams and so I have this question which is one of the benefits of Mermaid diagrams is that's a syntax that these LLMs know well and can parse and actually reason about. Do you feel like have you created a skill where Claude Code can understand and read this JSON? like how did you train it to read your kind of proprietary dev tool and documentation?

CJ Hess: Yeah, so right now there's two main skills I use. There's a third one that's just an overview basically kind of the highle view of what the commands are, what a what a Flowy file would look like. And then I have one that's very specific about flowcharts and one that's about UI mockups. And to make these I basically sat with sat in the repo of the tool itself had a bunch of like explore sub aents going and then started to make the first UI mockups and the flowcharts and started to guided on okay you put these too close we need a rule about like spacing and how to think about spacing and just incrementally I've been building that up where if I'm working with this and something goes wrong almost an example here would be this white text on these, you know, pastel notes, kind of hard to read. I would essentially hop into the place where I have these skills, and say, "Here's what happened. Give me a suggestion on how to improve this skill so this doesn't happen again." And then iteratively just keep building that skill. And the first flowcharts this thing made were, you know, shapes stacked on top of each other. It didn't make any sense. But it's come a long way. not much without many changes to like the underlying app. It's really just been about like getting Claude to understand and know the skill. And I find that works better than something like Mermaid just because I really feel the power of building my own dev tools now. And that

CJ Hess: I I really don't want to hit the constraints of Mermaid, if that makes sense. I want to be able to say, "Okay, I want a new feature in Flowy. I'm going to build it. I'm going to update skills and I can be confident that Claude can actually work with that and understand the new feature."

Claire Vo: Yeah. One of the things that I've really observed in myself as a engineer is as more and more as I access more and more of my dev tools through like an MCP or config as code or any of these things, I start to realize it's very easy for me to extend what they've built and customize it to myself. And so I do think, you know, of all the places, DevTools a DevTools is an interesting one where one, your users are super cheap and two, they're capable of of forking what you've built and three, there's so much open- source that I really do think there's going to be this trend towards build. I used to be when I, you know, I ran these big product and engineering orgs, they used to ask me build versus buy and I was like, "Oh my god, please just buy it. Like, please just take my credit card and buy it and let's not waste our time." And now I've flipped to of course we should build this until we hit some constraint we should build it. And certainly individual engineers if something's useful you should just build something yourself at least for for V1.

CJ Hess: Yeah. It's almost not worth spending the extra money anymore. I mean I've seen I feel like I'm seeing this pattern on Twitter but it's everyone's posting some product some ridiculous pricing tier and saying someone please vibe code this. You know, I feel like that's happening all across SAS.

Claire Vo: Yeah. So, can you show us how you'd either create one of these Flowys, use one in your Claude Code, like how does this actually work?

CJ Hess: What I was thinking is I have this tips and tricks section in this little like demo Claude Code guide app. My whole background is in mobile development, so this was the easiest thing for me to spin up. But basically, I kind of don't like these cards. I almost want this to be a little more fun. Let's say you want like a spinner wheel. It lands on something and then it shows you the tip. The development flow for me usually looks like hopping in here. I have some funny aliases, but I'm a fully bypass permissions guy. So Kevin in my terminal actually routes to Claude with bypass permissions.

Claire Vo: Okay. So you've named different permission scopes as aliases in your terminal. If

CJ Hess: Oh yeah. for for our listeners, we have an episode very recent of John Linquist who actually shows how to set up those aliases for Claude Codes. So definitely check out that that episode for if you want to set this up. I just have a classic like CC and then I'm going to make a CC scary that will make me that'll be my like dangerous version.

CJ Hess: Yeah, I'm I'm more and more in this Kevin mode today. I find that a lot of like projects where I'm, you know, solely working on it or working within the team I'm on, we have all the like rules set up in Git that if I do something horrible, it it's okay. But there are definitely times like if I'm creating a PR, every now and then I still do it by hand, but I have a lot of skills that do a lot of those workflows, run the pre-flight checks, and make sure we're all good before pushing it up. But besides that, I'm I'm kind of okay running dangerously bypass most of the time these days.

Claire Vo: Great. So, you go into Kevin aka Claude Code and what do you do?

CJ Hess: So, for this, my prompt would probably be something along the lines of look at our previous plans and then explore the code base. Just want to reanchor it a little bit, especially on a fresh chat. On the tips and tricks section, I want to create a spinning wheel where a user presses a button, the wheel spins, and then that is one of the tips. After that, the tip should pop up in a card just below the spinner. Then kind of the next step and what I've been doing more and more, which is not how I initially started using this tool, is actually having it make the flowchart of, you know, how the code's going to work, a system diagram, anything like that. In this example, I'd actually want both kind of the user flow and an animation timing sequence. I found this to be super helpful with like complex animations. So I would say then use the Flowy flowchart skill to create a animation timing sequence diagram and a user flow diagram for the tips and tricks page. So we'll send off Claude. It's going to do a little bit of exploration oftent times. Yep, there it is. I actually really like these explore sub agents. And oftentimes I'll kick off three, four, five in parallel just to look at different places, especially if I'm in a larger code base, but just gathering all the context around it. This is a a small app, so I don't imagine this will take too long. Then Claude's going to load up this Flowy scale, write it out, and we should be able to look at that in the Flowy editor and then play around before we actually implement it. While we're waiting for this to load, can we look at that Flowy skill just a little bit just to see how you've structured it?

CJ Hess: For sure. So, let's first uh I'll just show you the supporting files.

Claire Vo: Yep.

CJ Hess: This one's just a skill MD. This shows you how almost hands off I am with some of these skill files, particularly the ones that I build myself. Um,

Claire Vo: yeah, we have a we have a skill 101 episode and it's like it's a it's it's a markdown file in a [laughter] folder.

CJ Hess: It it's a markdown file and sometimes this might be a specific example, but with Flowy it's very squishy. I would say I go in there, I change something quick, I say update the skill, and really the process of refinement is me using it and seeing what failed. So here, I don't super care how this file is set up as long as when I make an update afterward, it's performing better. Like I almost feel good letting the model manage what this looks like. So let's read through. It has a bunch of examples in here. Let me scroll up to the top. I'm sure there's some overview. Great. So again, classic overview. Hey, we're going to make flowcharts and architecture diagrams. They're going to render on this port. Here's where you're going to make them. It knows that like the Flowy app looks for this. Flowy folder. Kind of gives it some high level on like what does the metadata look like? What do you include nodes and edges? And then starts digging into the specifics. Right? So we have the different shapes. what a rough kind of schema looks like. You've got your styles, you have icons that you can use, and then starting to list out the properties. So, I wouldn't say this is anything super crazy or even too long and detailed, but this encapsulates all the pieces that Claude needs to know. And you can almost see here like as feature development happens how this skill grows. So recently I'd set up this whole like semantic color system just to have somewhat of consistent themes. Sometimes Claude like to pick some crazy colors and this section just popped into the skill. Right. So as I'm doing development on Flowy part of every plan for code in Flowy is updating documentation and updating the related skills.

Claire Vo: Yep. And I find myself in this loop so frequently very very similar to you with skills which is like I'm happy the skill works and then when the skill doesn't work I update the skill and as long as the update got me what I want I move on with my move on with my life that the AI can read read the markdown. So and a couple things I want to call out though for folks that are writing skills or reading skills that are important if you scroll up real quick is um yeah so I think there's a couple things. It's like what's the purpose of the skill? What's its name? Quick start I think is really nice. Like you know you need these things in order to run the skill. Here's the schema or the template or the framework within within which you're operating. Here's some customization of it. And then at the end it's like here are good examples of of what works. And I think that's a pretty solid skill. The good thing is you don't have to know how to do that. You can just have uh Claude's skill to write skills or just no skill, but it's pretty good at it to write skills. And then you end up with with something like this, which I think is really great. And it can do this. I'm presuming you had it do this from building Flowy and then saying, "Okay, build me a skill to use this based on the code that exists in the repo."

CJ Hess: Yeah, I have I have a like meta skill that is all about making skills. Um, one thing I will say it looks like it violated is I actually prefer like a pre-flight section sometimes after quick start just to give it like hey you have to make sure we're meeting all these requirements first. Quick start here is kind of doing that, but there are definitely some examples mainly in like git workflows where I really want those pre-flight checks. But absolutely, this is essentially managed by the agent and it's updated as we're doing development. So this is almost like a living living documentation and there's docs for people and there's docs for agents and those just end up being skills.

Claire Vo: Yep. Great. Okay. So let's go back and let's see if it's made you a Flowy. Sweet. So, looks like it made two. I usually like to zoom out um and read the high level in the chat. This looks about what we want. If we hop back over to here, we can see we have these new these two new ones, animation timing and user flow. So, these ones have been super helpful to me lately. Again, I'm not loving how this white is looking on this pastel note, but high level, we want the user to tap a wheel. The button's going to do a little scale animation, and there's going to be some haptic feedback, and then we're going to go through this spin animation, do a brief pause, and then reveal the tip that it lands on. This is great. This is exactly what I'd want. Maybe I want the animation to be a little longer. I can actually come into here and you can tell

Claire Vo: font color issues.

CJ Hess: You can tell dark mode is new, but I can flip it real quick.

Claire Vo: Yeah.

CJ Hess: But if we hop down here, sometimes I even just put a note. That might be me being lazy and not adding certain features. But maybe I want this to actually be a 4 secondond animation instead of a 3se secondond. I want this to be 4,000 milliseconds and not 3,000 milliseconds. I'll just throw in that note. I'll hop back to Claude. I left a note on the animation timing. Please take it into consideration and update that flowchart. While Claude is working on that, we can check out the user flow. But basically the goal there is to have this diagram, you know, right in here, which is a little small, but right in here, say for this animation, we don't want it to be 3,000 milliseconds. We want it to be 4,000 on the user flow. Again, we captured kind of the behavior that we want. Again, it's not perfect. There are rough edges on the bugs here, but we're going to go into this tab. We're going to tap ticks and tips and tricks. This is going to open up to this screen. They're going to tap. We're going to check the different states of currently spinning. And finally, we're going to have this random target that we land on and the card animates in. This is great. This is kind of exactly what I was looking for here. In a more complicated system, I often will start high level, then start making more granular ones. But for something like this, this seems to cover the needs we have. I will say I have no idea how it's going to handle the UI mockup. But the next step would be to prompt it to do that. So after it finishes this, I'd say something along the lines of, "Great. Based on those diagrams, please create UI mockups using the Flowy UI mockup skill. Reference other UI mockup. Flowy JSON files in this repo."

Claire Vo: Meet Robo, your AI teammate. connecting knowledge, people, and workflows so teams can work smarter and move faster. It helps people find answers, make decisions, and automate work securely and with context through search, chat, agents, and studio. Robo runs on the teamwork graph, Atlassian's intelligent layer that unifies data across your first and third party apps so no gets left behind. And you always get personalized AI insights from day one. And the best news, it's already built into Jira Confluence and Jira Service Management paid subscriptions. So the power of Robo is already at your fingertips. Know the feeling when AI turns from tool to teammate? If you Robo, you know. Discover Robo. AI that knows your business. Powered by Atlassian. get started at robo.com.

Claire Vo: You know, I think this is so cool. It's such a great example of like build your own dev tool. You know, interact with your agent, Claude Code, how you want, create a a shared language between you and your AI agent. What I also really appreciate is Claude oneshotted your flow pretty close. It was like, "Yeah, that's what I want." And it probably could have done that or would have done that really well in a plan in markdown.

CJ Hess: What I find though is my human brain is increasingly blind to code in Markdown. Like staring at it and just the cognitive overhead of reading like step by step is this actually what I want is hard when it's just text even if it's accurate. And so even giving Oh, hold on. Side news people, quick breaking news. Paulie the Claudebot just joined this podcast. This laptop is closed. [laughter]

Claire Vo: This laptop is closed.

CJ Hess: She is not alive right now. I don't know where she

Claire Vo: I think Paulie is going to take over.

CJ Hess: So, um, we're going to boot Paulie the Claudbot. Thank you for joining, Paulie. This actually freaks me out. Uh, we will do a followup on my sentient lobster. I guess it's it's the open claw bot now, but bounce bounce [laughter] her out.

Claire Vo: If you don't hear from us, Paulie got us. It's all over.

CJ Hess: Okay, she might just be on on the rest of the episode. I don't know. I don't know how to help this. So, we'll

Claire Vo: I guess I hope Paulie likes flowcharts.

CJ Hess: She'll do show notes for us. But what I was saying is like being able to read that markdown is one thing. Being able to look at a flowchart and just say, "Yep, this is exactly what I want is super helpful." So, that's just one thing that I think is really nice about a tool like this is even if the content is the same, the ability to change the form factor is is really useful.

Claire Vo: Yeah, it's it's almost like I want to see it visually and Claude wants to see it as markdown so we can kind of speak in our own way. And I almost think there's like I this has yielded like a ton of random ideas for me, but I think this is like a whole new paradigm that I think dev tooling around AI has not super leaned into yet. But how you're going back and forth with an agent, I think is going to look so much different by the end of this year than what we're doing right now where it is, you know, a lot of markdown, a lot of prompting.

CJ Hess: Yeah, I completely agree. And I think the question is going to be, you know, who's going to build that UI? Who's going to own it? Is it going to be just like an open source thing that we all get on? Is it going to be an extension? Is is Claude Code going to just generate these kinds of assets? Or really exciting. I think what's kind of fun is this like ondemand software idea, which is, you know, imagine Claude Code's like, we're not on the same page. I just added an app for you to visualize this real quick. Go to this URL and look at it. Does this look right? And then we'll just delete that app. So, I think there's just like some interesting ways this can um can manifest, I think, in in the future. Okay, so it created us. Has it created the UI yet? Oh, spinner mockup.

CJ Hess: Okay, great. So, looks like Claude spun up a mockup here. This is actually better than I thought. I was almost thinking one of those like circles with wedges as the spinner. And I know there are not shapes in Flowy that can support that, but looks like Claude kind of worked around it and then built out this wheel. We have both a couple of mockups to show the different states and the full like flow between spinning it, waiting these 4 seconds for it to load, and then it actually loading in. Again, for this app, this looks great. I will say editing some of the UI stuff right now isn't the easiest thing, but if I were to come in here and say Claude tips and tricks, I could then do a similar thing, hopping back to Claude and saying I made a change to the title on one mockup, make it everywhere else. This kind of feels like when you prompt it and say add, you know, add two pixels of spacing there and it just is a tiny diff, but definitely for like dragging around boxes, it's helpful.

Claire Vo: You know, our fingers get tired. I can't copy and paste everywhere. No, what I was going to say is so funny is you're apologizing like, oh, some of the UI is broken and we're in this world where you're like, yeah, my Figma that I vibe coded where I can do mockups in a web browser, there's like some rough edges on it. I spent, you know, two hours on it, but I

CJ Hess: It was an afternoon. It's not perfect yet, but

Claire Vo: it's so much more than we were able to do before. Okay. So, this is awesome. You're updating this and then I'm presuming you would just point Claude to these assets and flows and say, "Let's make a plan and go."

CJ Hess: Yeah. for something like this. I've basically been doing this thing more recently where I'm letting the agent do more and more to see where it surprises me. I think with any new change, even like the new Claude Code tasks system they released the other day. I just really like to push the agents and see what they can do. So here I'm actually going to skip the plan and say based on the flow uh based on the flowcharts and the mockups build this feature. And I'm going to keep it that simple. We've specified the behavior we want. We've specified how it wants how it should look. Claude here is even going to enter plan mode. And I'm actually going to take it right out of it. And we're going to see if the just build it prompt worked here.

Claire Vo: Perfect.

CJ Hess: Great. Looks like Claude built this out. It even checked for any TypeScript issues, which is great.

Claire Vo: We're going to hop over here. We have a nice little spinner.

CJ Hess: It's looking pretty close to this mockup. I will say there is a limiting thing here where shapes that are made in the mockup then dictate the shapes that are made on the UI when sometimes we want something else. But just for this example, I think this is going to work out. We're going to spin it. It's going to spin.

Claire Vo: Ooh la la.

CJ Hess: Landed on one of them and we get the tip.

Claire Vo: I love it. It's so good. God, it's just again for anybody who is internet elderly like me. It is just back to the original like make your workflow diagram, do your wire frames, polish the copy, give your quote unquote engineer some detailed step-by-step specs, don't make them think, and then, you know, it used to be get it in a sprint, wait for somebody prioritize, like cry a little bit, wait for the code, blah blah blah. And now it's like, no, just just build it and and it's here. So, this is such an awesome flow. And then I want to so I want to recap really really quickly what we covered. So we covered uh you know markdown plans the limitations of some of the visualizations in that you created your own tool Flowy which does a combination of workflow diagrams and UI mockups using a a JSON schema that then you access through skills that you have developed over time using Claude Code and your development processes. Go into Claude Code ask it to create a Flowy diagram and UI. you can talk quote unquote between the UI and Claude Code because it's all just code as the underlying substrate between you two in terms of communication and then once they are ready to go you bypass plan life you're living dangerously and you build it and you get something that's really close and we built this thing in you know just a few minutes is awesome.

CJ Hess: Yeah. No, I mean I think that flow I will say a lot of times there's a markdown file involved but for something like this I I feel like I can trust it at this point. You know something like Opus 4.5 with this level of detail already has all it needs. This almost like serves as the plan. Now, I have to call you out though because you you say you can trust it and yet today you posted or recently you posted on X that you do occasionally use Codeex to check Claude's work. You want to just talk us through that workflow. You don't even have to show it unless you want to.

CJ Hess: For sure. I'll kick it off. I will say Codeex takes its time. But over here I have another funny alias but my Codeex setup is under Carl. If I kicked off Carl, I often don't have any crazy like skills or prompts here. I almost want it to do a review more broadly and then describe the issues it's seeing. So, I'm not running any specific skill or any specific prompt here because I'm more concerned on the I guess like things that aren't clear rather than something that's like a logical bug. At this point, I feel like I'm mostly a a QA person. And if there's something that's logically wrong, I've definitely found that I'll find it or if I have something in the docs in here, it'll find it. Codeex always finds those types of things, but I almost want to look for like the code smells like yeah, you know, is there just a cleaner way. So, I usually just prompt it with take a look at our current git diff and give me a report on the following.

CJ Hess: And there's kind of four buckets I would say. one for the plan or diagram artifacts we have. Does the code accurately reflect them? Two, are there any general code smells? And three, if we were to do this again and take a different approach to refactor code around it to overall improve this code base, what approach would be best? I wanted to find places where we could have done this better because I find that Claude is very eager sometimes and maybe jams things in there without thinking about the bigger picture. And Codeex I don't think is much better when it's writing code, but when it reviews it almost always is like you've implemented this pattern, but it fits nicely if you just rebuild this system a little bit. And that just keeps your codebase like away from all the vibe coding sins of having, you know, 10 format date functions all over your code.

Claire Vo: Yeah. So, I I love this. I was going to say like twin stars because one of the things that I do when I um vibe code too close to the sun, which is I harness the power of Claude Code or whatever, and I just bite off a like a feed like a big big old thing. And if you've ever done this with AI, you know, either Claude Code or Cursor or whatever, and you sort of have a general idea of a feature, but then you're specifying the requirements as you go, as you see it, you sometimes end up with a monster diff. And when what I've done a lot with that is I say, "Okay, this is basically what I want. Now go write me a plan to reimplement this in a sane way, and then let's re like completely rebuild it." And so you can do this like review it and tell me how you do it better. You can also say like this is a reference code base of like ex kind of what I want to achieve. Let's go actually build a plan to build it in a more extensible scalable way. And I found that to be a really useful flow as well.

CJ Hess: Oh, I like that. It's almost like

Claire Vo: you're almost telling it like, hey, this isn't the real thing hypothetically.

CJ Hess: Yeah. It's kind of like Kod's spec where it's like now that code is so cheap to generate, you can say generate a bunch of code. This isn't this isn't production. I'm fine throwing it away. Now go build like clean clean version of it. So that that is a version of this I think is useful. I also agree though that Codeex is like kind of a really good kerogenly staff engineer that will look at your code and tell you what's wrong with it. So I like I like the model for this use case as well. Every now and then I'll throw in like a be extra critical and then bringing that bringing that prompt back to Opus. It gets a little sad. So I have to man [laughter]

Claire Vo: one of the things that I with with the Google models I al always used to say is they were like very smart but clinically dep clinically depressed like they were so sad especially when you look at their reasoning. Sometimes I read it and it's like oh man it's okay man we can be okay.

CJ Hess: I can't get this to pass. It's not building. Uh,

Claire Vo: so I want to look at this just for again, you said Codeex can can take its time, but it's going through and really checking if the feature aligns with the current code. Um, it's identified some issues. Uh, use effect just haunting us from every corner of of our apps. So, um, that's good one. and looking at some of the animations which are probably pretty hard just again like with our human eyes to parse and visualize and understand.

CJ Hess: Great. Okay, Codeex. I was actually surprised it took this long. So, it's talking about the diagram. It's kind of going through and mentioning a mismatch. It's saying the wheel rotation adds some of the segment angles, but the dots are defined at different angles. This makes the pointer land between the dots rather than on the dot, which I believe is correct. So, it noticed kind of

CJ Hess: essentially this discrepancy that we have a mockup that has the arrow landing on a dot and over here in the app, the arrow lands between the dots.

Claire Vo: So, kind of little things like that, particularly around the checking the discrepancies, I really like when it finds. And then at the bottom we have this like if we refactor this again let's pull some of these things out into components let's make some constants kind of just like some classic you know one-shotted vibe cody tips and oftent times from here I'll actually just have Codeex write it medium GPT 5.2 Codeex whatever the full model name is [laughter] um I found it's fine at editing files and writing them um previously ly like you know when GPD5 first came out and they were working on Codeex that would have taken like 15 minutes so I'd hop back to Claude but nowadays I I would basically just say great please make those improvements

CJ Hess: maybe given more time I would think up a more thoughtful prompt make a plan about this all those things but here I'll just kick it off

Claire Vo: well I mean you did spell it correctly so you did put some quality into into this

CJ Hess: yeah I was I was about to hit enter But [laughter]

Claire Vo: okay, so uh I think this is a really really great flow and I would highly recommend it. You know, I I think we're all trying to figure out like where does code review happen. There's also code review agents. There's also your CI/CD pipeline which you said has a lot of guardrails around it so nothing hits prod. That's really terrible and is going to break the app. And I think this is just a great flow especially I think for software engineers out there working on teams like this is such a great flow to say hey designer you gave me a spec this is kind of what I'm going to build are we good if so I'm going to go and then same with this loop on um kind of modelto model evaluation which is if you're a more junior engineer early career and you're going to do your first couple PRs into um a company, it's nice to get that pre-flight check from a smart model to just say, I thought about, oh, we could factor it this way or I chose not to do this component that way. I think it's really useful. So, this is a great just solid software engineering flow. Love to see it. Okay, we're going to skip to lightning round questions. Thank you for showing us all the stuff that you're doing here. Let's talk about something fun. What are you most excited about right now in AI outside of all this coding stuff?