Leveraging Claude Code in Veryl Development

Introduction

As of March 2026, Anthropic is running the Claude for Open Source Program to support open-source developers. They provide a 6-month Claude Max 20x license to maintainers of popular repositories (based on GitHub stars) or widely downloaded NPM packages. I am grateful to have received this license, and I have been using it for the development of Veryl.

This was my first time using a coding agent, and while I only know basic commands like /init and /plan, I have already experienced a massive boost in productivity. In this article, I will share some of the things I accomplished within just three days of introducing it.

gitoxide Integration

The current veryl command calls the git command when Git operations (such as fetching dependencies) are needed, meaning the command must be available in the system PATH. While this is a requirement satisfied in almost all modern development environments, it is better to avoid unnecessary prerequisites, and I had been wanting to make the veryl command handle Git operations directly. Rust has a Git implementation called gitoxide which should be able to achieve this, but I had left it untouched for a long time because looking up how to use it was a hassle.

This time, I instructed Claude to "implement the same functionality using gitoxide by referring to the existing Git operation functions that call the command." It successfully implemented the features by referring to the gitoxide source code without any issues. Furthermore, it discovered a case where Git operations would fail due to the parallel execution of Rust's integration tests, and it even fixed a bug stemming from the timing of file locks.

Implementation of the Veryl Simulator

The native Veryl simulator I am currently working on was mostly complete in its broad structure, leaving only the task of adding support for more syntax. I gave it the relatively heavy task of "adding support for module instances." This is something that would have taken me several days, and I had been dreading it because of the many fine-grained implementation details involved.

Since this involved changing existing data structures, I initially had it create an implementation plan in plan mode. It wasn't perfect on the first try, and I had to point out a few things that were concerning, but once approved, it ran all the way through to implementation and passing tests. I don't think it took even an hour.

Although I had it fix some structural issues in the generated code, the details of the function implementations were largely left to the agent. Having confirmed it works, I fed it the remaining unsupported syntax one after another, and as of the time of writing, it supports almost all syntax. What I had originally planned to implement gradually over several months was finished in just a few days.

Veryl Code Generation

Having established that it is quite proficient in languages it already knows, I wondered how it would handle a language it doesn't know, so I had it write some Veryl code. I had tried having it write Veryl once before, but this time it was a slightly more complex example.

The subject was a 32-bit Wallace Tree multiplier. I had been using a simple counter as a benchmark for the Veryl simulator, but I wanted something more complex, so I decided to have it build that.

Surprisingly, just from the instruction "Write a 32-bit Wallace Tree and place it in crates/simulator/compare/wallace," it read that the compare directory contained equivalent code in both Veryl and SV, along with a Makefile for speed comparison against Verilator using hyperfine, and it reconstructed the same configuration on its own.

Also, while the generated Veryl code was syntactically incorrect at first, it recognized the proper grammar from the error messages output by the Veryl compiler and the Veryl code prepared as compiler test cases, and corrected it. Furthermore, it verified the execution results of the Veryl simulator itself, debugged the errors, discovered the syntax that the simulator did not yet support, and modified the code to avoid those parts, eventually getting it to pass.

When I previously attempted Veryl code generation, I had to use an approach of retrieving errors from the Veryl compiler via MCP, but now it seems that simply being able to use the CLI is sufficient.

Performance Analysis of the Veryl Simulator

Regarding the multiplier generated above, the Veryl simulator was initially only about 20% faster than Verilator. Since other circuits generally performed at least twice as fast, I had Claude investigate where the slowdown was occurring.

I only gave it the command to perform the performance comparison, but Claude used perf stat to check performance counters and discovered that the branch misprediction rate was high. It then found that the Veryl simulator's debug options included an output for the assembly generated by Cranelift, and pinpointed that a specific branch instruction in that assembly was the cause.

In the current Veryl simulator, all if statements are generated into binary as straightforward branches, but it became clear that it would be better to replace small branches with branchless select instructions.

Playground Improvements

For Veryl, I provide a Playground at https://doc.veryl-lang.org/playground/ where you can try out Veryl from a web browser. This was something I had hand-coded in HTML years ago while looking at the source code of some playground site, and it looked quite inferior compared to modern websites.

Unfortunately, I am a complete novice at web frontends and know nothing about web frameworks or modern JS/TS environments, so I threw a very rough prompt at it: "Make the playground look modern." In response, Claude proposed features such as:

• Adopting CodeMirror as the component for the code editor
• Responsive design
• Dark mode support
• Keyboard shortcuts
• URL sharing
• Collapsible log pane
• Build time display

I left the entire implementation to it. The code it first produced looked like what I wanted, but it didn't work at all. When I conveyed the error messages appearing in the browser console and the symptoms of the parts that weren't working, it eventually started working perfectly. (There might have been a way to connect Claude directly to the browser to have it check the rendering results, but I didn't do that this time, treating it as a test.)

Ultimately, the site went from the left to the right as shown below.

You can try the new Playground at https://doc.veryl-lang.org/nightly/playground/.

Conclusion

It has only been a few days since I introduced Claude Code, but I feel like I can implement as much as I want of the things I had previously thought, "It would be nice if I could do this eventually, but I don't have time now."

That said, it's not as if you can leave everything to it; it seems necessary to carefully handle the design and specification reviews with a long-term view. Also, before introducing it, I had the assumption that "it would be good at languages with abundant learning sources like web technologies, and bad at unknown languages like Veryl," but I felt that what is actually important is that Claude itself can run a loop of confirming results and improving. If you can build such an environment, it can handle even somewhat unusual tasks well, and if you can't, it will make mistakes even in common JS.

Having found that it is quite useful if you are careful about such points, I intend to focus on things like examining Veryl's language specifications in the future, while leaving the parts that can be automated to Claude.