Launched this week
Project Oryx
Decompose. Visualize. Understand codebases, legacy to AI.
4 followers
Decompose. Visualize. Understand codebases, legacy to AI.
4 followers
Explore and execute code visually across Python, Java, and C++. Sequence diagrams light up in sync as the program steps, built deterministically from the AST and live execution, not an LLM’s guess. Variables render as structured visuals: trees, containers, pointer graphs. Rewind to any point, change a value, and continue down a new branch. From legacy systems to AI-generated code, every codebase becomes legible.
Hi all, this is Jon, the main developer of Project Oryx.
This is an early evaluation release. The main reason it is here is to learn which features actually matter to working developers before investing deeper in any single one.
The core idea is to understand a codebase by watching it run. When stepping through Python, Java, or C++, the sequence diagrams light up in sync, built from the real AST and live execution rather than an LLM’s guess. Variables show up as visuals instead of walls of raw text.
The main areas currently being looked at are:
1. Enabling true branch editing to rewind code and edit variables at runtime. Currently, rewinding works for variable inspection only.
2. Generating semantic diagrams faster, with greater accuracy, and with lower token consumption.
3. Building fully themeable user interfaces.
Which of these features are genuinely useful day to day, and what feels missing? Honest, specific feedback is the entire point of this launch. The feedback button is in the lower-left corner of the workspace and it is the fastest way to send a note.
Thank you for taking a look.
One more thing: Project Oryx will be free, and the plan is to open source it further down the line. When local models are used, the code being analyzed stays on the user's own machine.
@projectoryx The "built from the AST and live execution, not an LLM's guess" line got me thinking. I've been reviewing a lot of AI-generated code lately, and the part that always trips me up is that it runs fine but the structure is all wrong if you actually trace it. Like instead of centralizing shared logic, it'll just duplicate the same block in five places because the model doesn't really refactor, it copies.
Curious whether you've seen that show up in the diagrams. Does AI-generated code look noticeably different from hand-written code when the sequence diagram renders the actual execution?
Hi @whetlan, thank you for the feedback. This is a sharp observation. Yes, this pattern shows up in both the AST and the semantic diagrams. If the architecture is done well, the sequence diagram converges, with many callers pointing at the same method. When something like this is detected, the repeated nodes are collapsed. (This was also done to prevent infinite graphs for recursive calls). In other words, shared logic shows up as lots of arrows landing on one collapsed node. If the logic is duplicated, the graph would look bloated, because each copy carries its own implementation. The case you described would render as five uncollapsable separate subtrees.
Architecture issues tend to show up easily in diagrams. However, I have not run a rigorous study of hand-written versus generated code.
At this point, all it does is build the sequence diagram, and the AI summarizes that into a semantic diagram. The user is still left to decide whether those calls are an architecture issue. So I think you have pointed out something worth looking into. It would be nice if the application could detect and warn on obvious architecture issues too. I’ll get this one on the roadmap.