How I AI: CJ Hess on Building Custom Dev Tools and Model-vs-Model Code Reviews

CJ Hess has built one of the most practical AI engineering setups I've seen: custom tools that turn vague prompts and messy ASCII diagrams into usable visual plans, mockups, and production features. He's not just using Claude to write code. He's building an entire workflow around it, complete with his own planning system, skills, and review loops.

Developer tooling used to mean choosing an IDE, tweaking some configs, and maybe arguing about linters. Now individual engineers can build lightweight tools around their own workflows in a weekend. CJ is a great example of that shift. Frustrated by text-heavy planning and ugly ASCII diagrams, he built a visual layer for collaborating with Claude Code. The result feels less like prompting a chatbot and more like building a shared interface between human intuition and the model.

In this episode of How I AI, CJ walks through two workflows that materially improve how he builds software with AI. First, he shows how Flowy converts structured JSON into interactive flowcharts and UI mockups that Claude can reliably build from. Then he layers on a second review model, GPT-5.2 Codex, to act like a skeptical staff engineer reviewing Claude's work for bugs, code smells, and architectural shortcuts. The combination is fast, surprisingly practical, and much closer to real software engineering than pure vibe coding.

Visual planning and feature building with a custom tool, Flowy

Develop Features with AI Using Custom Visual Planning Tools: Turn a feature idea into a user flow, timing diagram, and UI mockups that your coding agent can use as the implementation plan.

One of the biggest challenges in AI-driven development is effectively communicating complex plans and user flows to the model. While LLMs are great at generating plans in Markdown, the ASCII flowcharts they produce can be messy and hard to interpret. As CJ put it, "There's always this misalignment of that edge character." To solve this, he didn't wait for a new feature, he built his own solution: Flowy.

Flowy is a lightweight dev tool CJ built that renders JSON files as clean, interactive diagrams. He uses it for UI mockups, system diagrams, and user flows, while keeping the underlying structure readable for Claude. Instead of forcing humans to stare at Markdown flowcharts or forcing models to reason from screenshots, Flowy gives each side a format it's actually good at working with.

The initial idea and prompt

CJ wanted to replace a static 'Tips & Tricks' section in a demo app with a more interactive spinning wheel. Instead of just describing this in text, he decided to use his Flowy workflow. He started by giving Claude a high-level prompt in his terminal, using a custom alias kevin that calls Claude Code with bypass permissions.

"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 use the flowy flowchart skill to create a animation timing sequence diagram, and a user flow diagram for the tips and tricks page."

The prompt pulls double duty. It describes the feature CJ wants, then explicitly tells Claude to invoke a custom Flowy skill that generates the planning artifacts in the correct JSON format.

Generating flowcharts with a custom skill

Using CJ's custom skill, Claude Code generated two JSON files: one for the user flow and another for animation timing. Inside Flowy, those files immediately became readable diagrams instead of walls of text or broken ASCII boxes.

The skill itself is a simple Markdown file (skill.md) that CJ developed iteratively. It defines the JSON schema for nodes and edges, available styles, colors, and provides examples. This skill acts as the documentation that teaches Claude how to use Flowy correctly.

Iterating visually and generating UI mockups

This is where the workflow gets interesting. CJ noticed the animation duration was set to 3 seconds when he actually wanted 4. Instead of editing raw JSON, he updated the timing directly inside Flowy's visual editor, which automatically modified the file underneath. Then he pointed Claude back to the updated diagram so it could continue from the revised state.

From there, he asked Claude to generate UI mockups based on the diagrams.

Great. Based on those diagrams, please create UI mockups using the flowy UI mockups skill reference, other UI mockup flowy JSON files in this repo.

Claude generated another Flowy file showing the spinner wheel across multiple states: before spinning, during the animation, and after revealing the selected tip. The mockups were low fidelity, but detailed enough to guide implementation without a separate design pass.

From visual plan to live feature

Once the diagrams and mockups were in place, CJ skipped the usual long Markdown implementation plan and gave Claude a much simpler instruction:

Based on the flowcharts and the mockups, build this feature.

Because the flowcharts and mockups already captured the behavior and structure clearly, Claude had enough context to build the feature directly. Within a few minutes, CJ had a working spinner wheel that matched the Flowy diagrams closely enough to ship and iterate on.

Quality control with model-vs-model code reviews

Implement Model-vs-Model AI Code Reviews for Quality Control: Use one model to build quickly and a second model to review the diff for plan mismatches, code smells, and better architecture before applying the fixes.

Claude is incredibly fast and capable, but as CJ says, "Claude is very eager sometimes and maybe jams things in there without thinking about the bigger picture." Vibe coding still creates technical debt if nobody checks the work carefully. CJ's solution is to hand Claude's output to GPT-5.2 Codex for review.

He describes Codex as the critical staff engineer in the room. Claude is more collaborative and steerable during implementation, while Codex is better at slowing down and questioning the code structure, edge cases, and maintainability. Together, the two models cover very different strengths.

Kicking off the review with 'Carl'

After Claude built the spinner feature, CJ invoked his second AI assistant, aliased as carl in his terminal, which is configured to use Codex. He fed it a prompt asking for a detailed review of the code changes.

"Take a look at our current git diff and give me a report on the following:

1. Does the code accurately reflect the plan/diagram artifacts?

2. Are there any general code smells?

3. 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?"

The prompt pushes Codex to evaluate the implementation from three angles at once: whether it matches the original diagrams, whether the code quality holds up, and whether there's a cleaner architectural approach hiding underneath the quick implementation.

Analyzing the feedback

Codex returned a surprisingly thorough review. It caught several subtle issues that would have been easy to miss during a fast implementation pass:

This is the kind of review loop that keeps small AI-generated features from quietly accumulating into a messy codebase.

Implementing the fixes

After Codex identified the issues, CJ simply asked it to implement the fixes it had recommended.

great, please make those improvements

Codex refactored the feature, cleaned up the structure, and fixed the implementation issues it had flagged during review. The final result was closer to what you'd expect from a careful engineering pass than a one-shot generated feature.

Conclusion: Build your own tools, trust but verify

What stood out to me most about CJ's workflow is how little patience he has for awkward tooling constraints. If Markdown diagrams are hard to reason about, he builds a visual layer. If AI-generated code drifts toward technical debt, he adds another model to review it. AI makes custom tooling cheap enough that individual engineers can now shape their own environments instead of waiting for vendors to solve every workflow problem.

The multi-model review loop also feels genuinely useful. Using one model for generation and another for critique creates a healthier balance between speed and rigor. Claude Opus 4.5 handles the fast, collaborative implementation work, while Codex acts more like a skeptical reviewer looking for weak spots, inconsistencies, and cleanup opportunities.

I left this conversation thinking less about prompts and more about interfaces. CJ's workflows work because he keeps reducing friction between what he wants, what he can visualize, and what the model can reliably interpret. If your AI workflow keeps breaking down in the same places, there's a good chance the answer is not another prompt tweak. It might be a small custom tool, a better artifact format, or a tighter feedback loop between models.