A senior dev once told me:

"You ship 100 projects, you're competent. You write an editor, you're intermediate. A browser, you're advanced. An OS, you're a god."

I crossed 100 a long time ago. CLI tools, web apps, mobile, games, internal business stuff, whatever. But the editor part stayed unfinished. I could write a notepad with a compile button, sure. Anything with code completion or jump-to-definition? It always stalled. There were better editors out there, no point shipping mine, and I just kept using the ones other people made.

This is the story of the editor that sat as a draft on my hard drive for 20 years, and how it finally became v0.8.

The thing I shipped is called BerryCode, a Bevy game engine IDE built in Bevy itself. It's open-source on GitHub.

Two decades of wanting an editor I never finished

The first time I felt the urge to write my own editor, I was using JCPad, a free Japanese teaching IDE for Java that schools handed out in the
early 2000s. Tiny tool by today's standards, but when I hit the run button and a compiler kicked in, I was a kid thinking "I want to build something like this."

Then I spent the next 20-something years using other people's editors.

• Eclipse: heavy. But the moment I saw refactoring and completion in action, I was hooked.
• IntelliJ: the first IDE I ever paid money for, and felt right doing it. Still locks up after a few days as the heap fills.
• VS Code: fast, infinitely extensible. But the extensions create their own version-mismatch hell: slow startup, conflicts, breaking changes between releases.
• Unity / Unreal: the obvious choice for games. Both excellent. Both not-quite-mine in a way I can't ignore. Bevy maturing as a fully-open-source Rust engine made me realize I could finally have something I controlled end-to-end.

Good tools, all of them. And I always had something to complain about.

There was another reason, more recent. My 10-year-old started writing Roblox games and was getting decent at code. I wanted to point him at Unity, but it's heavy and the licensing scares me for a kid. More importantly, I'd rather he learn how memory and CPU and concurrency actually work than mess around with C# garbage collection. Go or Rust, basically. And there was no editor that felt right for "the next thing after Roblox, for kids."

The hypothesis I kept coming back to:

"What if the editor itself ran on the GPU?"

Every CPU-based editor gets heavier the more extensions you stack on it. If text rendering, scene preview, all of it, lived on the GPU instead, you'd get game-engine-level responsiveness. Plus you could build it specifically for the language and engine you actually use, instead of bolting plugins onto a general-purpose tool.

The hypothesis sat unproven for years. The tooling wasn't there. Then WGPU matured enough that you could drive the GPU end-to-end from Rust, and Bevy became viable as a real game engine, and suddenly the idea was tractable.

January 2026, finally starting

2026-01-11  feat: Integrate berry-api gRPC server and fix session management

First commit.

I bet on Dioxus for the first week. React-style components looked clean, I shipped 26 commits in a single day. A week later I knew it was wrong.

2026-01-17  feat: Complete egui migration and add new features

Switched to egui. Immediate mode meant I could sync directly to Bevy's frame, which made the "the editor runs on the same engine as the games it edits" idea actually structural instead of aspirational.
Then nothing happened for three months.

I had under 50 commits in that whole stretch. I added LSP, played with LLM routing, wired up an AI review workflow. Forward motion, but slow. The voice in my head kept saying "yeah, this editor won't ship either." I'd more or less accepted the project would take years.

April 17: Claude Code arrived

The turning point has a date.

2026-04-17  feat: Implement Unity-class Scene Editor (76 phases, 232 tests)

That commit message tells you the whole story. 76 phases and 232 tests landed in a single commit. The Unity-class scene editor I'd planned to spend three months on stood up as a skeleton in a day.

The next three weeks logged 230 commits.

What used to be v0.2 went out as v0.8 three weeks later.

What actually changed was my role.

Before Claude Code, I was the one writing the code. After, I was the architect and the reviewer. The split looked like this:

• AI: boilerplate, refactors, scaffolding, tests
• Me: architecture decisions, library choices, UX, dodging egui's footguns, final review

To stop the model from making the same mistake twice, I started keeping a CLAUDE.md at the repo root. It's loaded into every agent run. Contents are pure "do not do this" and "this is a trap":

- Don't spawn `PrimaryEguiContext` twice. Plugin spawns one and only one.
- Trust `cargo check`, not rust-analyzer's diagnostics.
- Codicon glyph codepoints are not what their names suggest. Verify in the .ttf with fonttools.

Add a line every time I bang my head against a wall. Six months in, it's over a hundred lines.

People will look at this from outside and bucket it as "AI wrote it." That's not quite right. It feels more like the AI is the hands, and I'm the architect plus the reviewer. Claude Code writes, I read, I throw out what doesn't fit. When something doesn't compile, I paste the error and we fix it. The design comes from me.

Three months of silence, then three weeks of acceleration. v0.8 shipped.

At the gate of "intermediate"

Even after v0.8 went out, I don't feel like the editor is done. Editing scripts, scene editing, the ECS inspector, terminal, debugger, release pipeline. Every time I touch any of it, three more missing things appear.

Editors don't get finished. That's probably what writing one means.

But the project I'd been carrying around half-written for 20 years is finally in motion. That part is real.

Hundred projects shipped, editor under construction. By my old colleague's standard, I might have just stepped onto the gate of "intermediate." Browser next? Operating system? Both feel out of reach for the foreseeable future. Thinking about it is its own kind of fun.

And soon I'm going to hand BerryCode to my son. The bridge from Roblox (Lua) to Rust, if it actually works as a bridge. That's the real test.

Links

• GitHub: https://github.com/KyosukeIshizu1008/berryscode
• v0.8.2 release: https://github.com/KyosukeIshizu1008/berryscode/releases/tag/v0.8.2
• Japanese original (Zenn): https://zenn.dev/berrycode/articles/c8236fba64503b
• X: https://x.com/KyosukeIshizu