with minimal annotations • Provides editor support OptCarrot An 8-bit machine simulator • Written in Ruby • A long-loved Ruby performance benchmark 5.ti| 1 + "str" TypeError Do you mean: 5.times
support for meta-programming • Native support for Struct.new / Data.define • # typeprof:ignore (by x-smasato) • argument forwarding (by pvcresin) • RBS Record Type (by sinsoku)
in batch mode • 669 errors! • All are "undefined method" errors • All should be phantom errors • We want zero errors on OptCarrot • The natural goal if you use TypeProf • What did it take to bring 669 errors down to zero? typeprof --show-stats --show-errors lib/optcarrot/**/*.rb Error type Count nil#[], nil#+, etc. 223 {false, true}#[], etc. 368 {ClassName}#... 183
"key points" • Add RBS to methods where data flow converges • Superficial but easy; good as prevention • Strategy 2: Find and fix the root cause • Find and fix what injects unexpected types • Harder but fundamental; satisfying when it works :-)
RBS over inferred types • CPU#fetch is a bottleneck of data flow • Same goes to CPU#store and #peek16 • 669 → 177 errors(-74%) #: (Integer) -> Integer def fetch(addr) @fetch[addr][addr] end OptCarrot CPU GPU RAM ROM CPU#fetch
converges • As OptCarrot's author, I knew CPU#fetch mattered • Big-picture knowledge of the codebase is required • New option: AI • Claude Code identified CPU#fetch as the key • With good tooling and harness, this could be promising
Fix the cause Changes 3 lines of RBS 1 line of Ruby Effect 669→177 669→175 AI Could find key points Too hard for now Note Also useful preventively A type-aware developer wouldn't write such code?
• TypeProf cannot tell what readers are defined → Wrote RBS [:loglevel, :romfile, …].each do attr_reader it end class Optcarrot::Config def loglevel: -> Integer def romfile: -> String? ... end
• TypeProf work: hand-tuned, improving TypeProf in parallel • Steep/Sorbet work: mostly Claude Code, less polish • The checks are never equivalent • Basically, Steep/Sorbet performs stricter verification • TypeProf work tolerates "untyped" inferred results
Code, Codex, etc.? • Writing Ruby in an editor → way less often • Even TypeProf development: Claude Code writes, I review the git diff • The main propose of TypeProf was an editor support • The question: What role should TypeProf play in the AI era?
JS are fastest, cheapest, and most stable from my article "Which Programming Language Is Best for Claude Code?" https://dev.to/mame/which-programming-language-is-best-for-claude-code-508a Ruby with Steep is not so good…
your Ruby code • So, it shouldn't slow AI down • TypeProf helps AI agents with inferred types? • As an MCP server, maybe? But… • For now, I continue to improve TypeProf for human • Let the answer emerge from practice
much fewer changes than other type checkers • Main changes • Write RBS only for "key points" • Add "|| raise " • Use "# typeprof:ignore " • Ruby without explicit types fits the AI era • TypeProf's "inference w/o annotations" may matter more than ever
Editor UX: not yet evaluated • Checking rigor: likely insufficient • Apply to larger / different codebases • Also, TypeProf improvement is also required • Speed, precision, more DSL support • AI integration and experiment