A video-based Blitzy review following a Monero C++20 migration: three days of ingestion, a technical specification, failed Windows builds and a human fix.
Blitzy spent three days ingesting a Monero repository, produced more than 40 pages of technical documentation and attempted a C++20 migration. Windows builds still failed. The reviewer fixed the remaining issue using a string-conversion helper already in the project, then reported that all 46 checks passed.
The video above follows that process. This article explains the work shown and the difference between Blitzy's workflow and tools such as Claude Code. The reviewer says Blitzy invited him to test the platform and describes a partnership providing sandbox access to his audience. Belliste's review is based on his demonstration, not a separate hands-on test.
Blitzy coordinates AI models and specialized agents around a repository. The workflow shown in the video starts with source-control access, codebase ingestion and a generated technical specification. The developer defines the task and reviews the plan before examining the resulting changes.
The reviewer chose Monero because he had contributed to it previously. He describes the core as roughly 350,000 lines of code. He forked the repository, selected a refactoring goal, configured the development environment and supplied additional project context.
Ingestion took three days in this run. The resulting specification covered the technology stack, built executables, architecture and relationships between components. Flowcharts gave the reviewer a way to follow those relationships without navigating every source file first.
That documentation is useful if it matches the repository. Before relying on it for a migration, a developer should check the sections describing the build, platform dependencies and the code that will change. The length of the document is less important than whether it answers those questions correctly.
After reviewing the specification, the developer wrote a prompt defining what the migration should and should not change. Blitzy generated an action plan, made changes and checked its output against tests and the plan.
Its executive summary reported that it had completed 77% of the work, leaving the rest for a human. This was the platform's estimate; the video does not explain its calculation. It is not a measured 77% saving in engineering time.
The outstanding work involved Windows, MinGW and MSYS2 checks. The reviewer investigated the reported build error and found a problem with wide-character output to a narrow stream.
The reviewer resolved the error by using an existing UTF-16-to-UTF-8 conversion utility. Knowing the codebase helped: he could use a helper already available rather than introduce another conversion implementation.
One detail in the narration needs correcting. The relevant wide-character insertion overloads for narrow streams were deleted in C++20, not merely deprecated. The C++ draft declarations show those deleted overloads. That explains why the change can stop a build rather than produce only a deprecation warning.
After merging his correction into the generated branch, the reviewer reported 46 passing checks. The practical result was an AI-assisted migration that still required platform-specific diagnosis and a human patch.
The reviewer shows two features that help explain the generated patch:
These features can make a large patch easier to navigate. The explanations still need to agree with the code, and a passing test suite does not remove the need for review.
The video also presents a cuDF example involving signed-integer overflow and narrowing conversions. It illustrates another kind of proposed change, but the Monero migration is the case followed through to a reported human fix and passing checks in this review.
The distinction is not simply "platform versus IDE." Claude Code can run in a terminal and other supported interfaces, inspect repository files, edit code and execute commands.
| Aspect | Blitzy in this demonstration | Claude Code |
|---|---|---|
| Starting point | Repository import and a dedicated ingestion phase | A coding session with access to the repository |
| Project context | Generated specification, architecture diagrams and a plan | Repository files, project instructions and tool output |
| Review material | Grouped changes, review notes and build checks | Changes and tool results available for developer review |
| Result on this migration | Human correction followed by 46 reported passing checks | No equivalent run is shown in the video |
The video supports a comparison of the working process. It does not establish which tool would complete this migration faster, more cheaply or with fewer errors. That would require the same task and starting commit, with both runs' costs, time and manual corrections recorded.
The reviewer cites an 84.95% SWE-bench Pro score. Blitzy's own website also publishes that figure. It is a benchmark claim about the evaluated system, not a result from running Claude Code against the Monero task. Blitzy's published claims
The reviewer describes a product costing around $500,000 a year. At the time of checking, Blitzy's site lists $500,000 annually for its Core engagement, alongside other evaluation and deployment options. That is not one universal price for every customer. Check the current pricing and sandbox terms before planning a trial.
Blitzy produced substantial project documentation and a migration patch, then identified work it wanted a developer to finish. The developer supplied a project-specific correction before reporting passing checks.
For a team considering a similar migration, the next test should use a representative branch and the same checks required for any other contribution. Record the time spent reviewing the specification, examining the patch and fixing failures—not only how much code the platform generated.
The documentation and grouped review workflow are worth examining. The Windows failure is worth examining too: it shows exactly where the developer's knowledge was still needed.
No. The reviewer supplied a correction for a Windows-related build issue, then reported that 46 checks passed.
It is Blitzy's own estimate shown in the video. Its calculation is not explained, so it should not be treated as a measured share of engineering time saved.
This video does not establish that. It shows a Blitzy migration, not a controlled test of both tools on the same task.
Three days is the time reported for this Monero run. Other repositories and configurations may take a different amount of time.
He says Blitzy invited him to test the product and describes a sandbox-access partnership for his audience.
