[1]: https://kerrick.blog/articles/2025/use-ai-to-stand-in-for-a-...
5,047 karma · joined May 24, 2012
[1]: https://kerrick.blog/articles/2025/use-ai-to-stand-in-for-a-...
The main library (rubygem) has 3,662 code lines and 9,199 comment lines of production Ruby and 4,933 code lines and 710 comment lines of Rust. There are a further 6,986 code lines and 2,304 comment lines of example applications code using the library as documentation, and 4,031 lines of markdown documentation. Plus, 11,902 code lines and 2,164 comment lines of automated tests. Oh, and 4,250 lines in bin/ and tasks/ but those are lower-quality "internal" automation scripts and apps.
The library is good enough that Sidekiq is using it to build their TUI. https://github.com/sidekiq/sidekiq/issues/6898
But that's not all I've built over this timeframe. I'm also a significant chunk of the way through an MVU framework, https://rooibos.run, built on top of it. That codebase is 1,163 code lines and 1,420 comment lines of production Ruby, 4,749 code lines and 521 comment lines of automated tests. I need to add to the 821 code lines 221 comment lines of example application code using the framework as documentation, and to the 2,326 lines of markdown documentation.
It's been going so well that the plan is to build out an ecosystem: the core library, an OOP and an FP library, and a set of UI widgets. There are 6,192 lines of markdown in the Wik about it: mailing list archives, AI chat archives, current design & architecture, etc.
For context, I am a long-time hobbyist Rubyist but I cannot write Rust. I have very little idea of the quality of the Rust code beyond what static analyzers and my test suite can tell me.
It's all been done very much in public. You can see every commit going back to December 22 in the git repos linked from the "Sources" tab here: https://sr.ht/~kerrick/ratatui_ruby/ If you look at the timestamps you'll even notice the wild difference between my Christmas vacation days, and when I went back to work and progress slowed. You can also see when I slowed down to work on distractions like https://git.sr.ht/~kerrick/ramforge/tree and https://git.sr.ht/~kerrick/semantic_syntax/tree.
If it keeps going as well as it has, I may be able to rival Charm's BubbleTea and Bubbles by summertime. I'm doing this to give Rubyists the opportunity to participate in the TUI renaissance... but my ultimate goal is to give folks who want to make a TUI a reason to learn Ruby instead of Go or Rust.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
In The Resilient Farm and Homestead by Ben Falk, you'll find a sidebar on page 28: Oil to Soil--Use it or Lose It: Leveraging the Cheap-Oil Window for Maximum Effect. He says, "we have made the conscious decision to take advantage of the small window of time still remaining with which to develop intergenerational land and infrastructure systems, which greatly enables long-term production of the site without any oil input for hundreds if not thousands of years."
I think of subsidized LLM tokens like this. Use them to build developer tools. Ideally, these developer tools will work with and without further LLM use. Then it won't matter if token prices fall forever, or if the subsidies end and nobody can afford AI-assisted development.
Plenty of books are printed non-bleached paper, which is more of a cream color, to reduce the contrast and reflectivity of the background.
For example, it was able to read the ANSI and figure out that a snapshot had changed because an upstream bug properly rendered bold and underline when it hadn't before.
[0]: https://git.sr.ht/~kerrick/ratatui_ruby/tree/trunk/item/lib/...
- README.md explains the basics https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/REA...
- CHANGELOG.md is better than the commit messages, and filtered to only what app devs using the library likely care about: https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/CHA...
- doc/ holds the Markdown documentation, which I heavily reviewed. https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/doc
- lib/ holds the Ruby source code of the library, which I heavily designed and reviewed. https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/lib
- examples/ holds the Ruby source code of some toy apps built with the library. https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/exa...
- bin/ holds a few Ruby scripts & apps to automate some ops (check out announce) https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/bin
- tasks/ holds some more Ruby scripts & apps to automate some ops (most I did not read, but I heavily designed and reviewed bump and terminal_preview) https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/tas...
- ext/ holds the Rust source code of the library, which I did not read most of. https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0/item/ext
I was having a lot of fun, and part of the reason I took deprecations and releases seriously was because I hoped to encourage adoption. And that I did: https://todo.sr.ht/~kerrick/ratatui_ruby/4 and https://github.com/sidekiq/sidekiq/blob/main/bin/tui
Just Christmas Vacation (12-18h days): https://git.sr.ht/~kerrick/ratatui_ruby/log/v0.8.0
Lastest (slowed down by job & real life): https://git.sr.ht/~kerrick/ratatui_ruby/log/trunk and https://git.sr.ht/~kerrick/ratatui_ruby-wiki/log/wiki and https://git.sr.ht/~kerrick/ratatui_ruby-tea/log/trunk
Everything is out there to inspect, including the facts that I:
- was going 12-18 hours per day
- stayed up way too late some nights
- churned a lot (+91,034 -39,257 lines)
- made a lot of code (30,637 code lines, 11,072 comment lines, plus 4,997 lines of markdown)
- ended up with (IMO) pretty good quality Ruby (and unknown quality Rust).
This is all just from the first commit to v0.8.0. https://git.sr.ht/~kerrick/ratatui_ruby/tree/v0.8.0
What do you think: is this fast, or am I just as silly as the live-streamer?
P.S. - I had an edge here because it was a green-field project and it was not for my job, so I had complete latitude to make decisions.
ratatui_ruby % git remote -v
origin https://git.sr.ht/~kerrick/ratatui_ruby (fetch)
origin https://git.sr.ht/~kerrick/ratatui_ruby (push)
ratatui_ruby % git checkout v0.8.0
HEAD is now at dd3407a chore: release v0.8.0
ratatui_ruby % git log --reverse --format="%ci" | head -1 | read first; \
echo "First Commit: $first\nHEAD Commit: $(git show -s --format='%ci' HEAD --)"
First Commit: 2025-12-22 00:40:22 -0600
HEAD Commit: 2026-01-05 08:57:58 -0600
ratatui_ruby % git log --numstat --pretty=tformat: | \
awk '$1 != "-" { \
if ($3 ~ /\./) { ext=$3; sub(/.*\./, "", ext) } else { ext="(no-ext)" } \
if (ext ~ /^(txt|ansi|lock)$/) next; \
add[ext]+=$1; rem[ext]+=$2 \
} \
END { for (e in add) print e, add[e], rem[e] }' | \
sort -k2 -nr | \
awk 'BEGIN { \
print "---------------------------------------"; \
printf "%-12s %12s %12s\n", "EXT", "ADDED", "REMOVED"; \
print "---------------------------------------" \
} \
{ \
sum_a += $2; sum_r += $3; \
printf "%-12s %12d %12d\n", $1, $2, $3 \
} \
END { \
print "---------------------------------------"; \
printf "%-12s %12d %12d\n", "SUM:", sum_a, sum_r; \
print "---------------------------------------" \
}'
---------------------------------------
EXT ADDED REMOVED
---------------------------------------
rb 51705 18913
md 20037 13167
rs 8576 3001
(no-ext) 4072 2157
rbs 2139 569
rake 1632 317
yml 1431 153
patch 894 894
erb 300 30
toml 118 39
gemspec 62 10
gitignore 27 4
css 22 0
yaml 18 2
ruby-version 1 1
png 0 0
gitkeep 0 0
---------------------------------------
SUM: 91034 39257
---------------------------------------
ratatui_ruby % cloc .
888 text files.
584 unique files.
341 files ignored.
github.com/AlDanial/cloc v 2.06 T=0.26 s (2226.1 files/s, 209779.6 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Ruby 305 4792 10413 20458
Markdown 60 1989 256 4741
Rust 32 645 530 4400
Text 168 523 0 4358
YAML 8 316 17 961
ERB 3 20 4 246
Bourne Again Shell 2 24 90 150
TOML 5 16 10 53
CSS 1 3 8 11
--------------------------------------------------------------------------------
SUM: 584 8328 11328 35378
--------------------------------------------------------------------------------You can see this pattern in my AI attribution commit footers. It was such a noticeable difference to me that I signed up for Google AI Ultra. I got the email receipt January 3, 2026 at 11:21 AM Central, and I have not hit a single quota limit since. Yo
I think the following things are true now:
- Vibe Coding is, more than ever, "autopilot" in the aviation sense, not the colloquial sense. You have to watch it, you are responsible, the human has do run takeoff/landing (the hard parts), but it significantly eases and reduces risk on a bulk of the work.
- The gulf of developer experience between today's frontier tooling and six months ago is huge. I pushed hard to understand and use these tools throughout last year, and spent months discouraged--back to manual coding. Folks need to re-evaluate by trying premium tools, not free ones.
- Tooling makers have figured out a lot of neat hacks to work around the limitations of LLMs to make it seem like they're even better than they are. Junie integrates with your IDE, Antigravity has multiple agents maintaining background intel on your project and priorities across chats. Antigravity also compresses contexts and starts new ones without you realizing it, calls to sub-agents to avoid context pollution, and other tricks to auto-manage context.
- Unix tools (sed, grep, awk, etc.) and the git CLI (ls-tree, show, --stat, etc.) have been a huge force-multiplier, as they keep the context small compared to raw ingestion of an entire file, allowing the LLMs to get more work done in a smaller context window.
- The people who hire programmers are still not capable of Vibe Coding production-quality web apps, even with all these improvements. In fact, I believe today this is less of a risk than I feared 10 months ago. These are advanced tools that need constant steering, and a good eye for architecture, design, developer experience, test quality, etc. is the difference between my vibe coded Ruby [0] (which I heavily stewarded) and my vibe coded Rust [1] (I don't even know what borrow means).
[0]: https://git.sr.ht/~kerrick/ratatui_ruby/tree/stable/item/lib
[1]: https://git.sr.ht/~kerrick/ratatui_ruby/tree/stable/item/ext...
It's Ratatui & Crossterm bindings (via Magnus for Rust<->Ruby), plus a thin veneer of DX niceties and Rubyist improvements.
It's a rendering library that uses the immediate-mode paradigm. It is not (yet?) a component library or application framework. However, it's the core primitive on which you can build with architectures such as MVU (Elm-like) or Components (Smalltalk/DOM-like). The repository has example applications, including a small preview of what each of those architectures look like with the library (examples/app_all_events/ and examples/app_color_picker/ respectively).
I'm nearing v1.0.0 (launching v0.7.0 this evening) and I would love your feedback! https://sr.ht/~kerrick/ratatui_ruby/
P.S. - This is heavily AI-assisted. Depending on how you view the meaning of "vibe coding" either the whole thing, or just the rust side is vibe coded. I've had a heavy hand in the design and implementation of the Ruby side.
For a more practical example, creating bindings from dynamic-language-A for a library in compiled-language-B is a genuinely useful task, allowing you to create things that didn't exist before. Those things are likely to unlock great happiness and/or productivity, even if they are derived from training data.
See also: https://git.sr.ht/~kerrick/ratatui_ruby
For example, I do not know rust but I've been using AI to make https://git.sr.ht/~kerrick/ratatui_ruby at a really rapid pace.
Gene Kim et al., The Phoenix Project. This book reinvigorated my love for management, which I lost in 2021–2022. I'm still an IC, but I decided to stop refusing management roles.
Kent Beck, Extreme Programming Explained, 2nd Edition. This book lit a fire under my ass to figure out better ways of working. I followed it up with the next one in a book club at work.
James Shore et al., The Art of Agile Software Development, 2nd Edition. This book gave me hope that a productive, humanist, productivity-oriented workflow can work in today's software world. I read it with my teammates in a book club at work, including the software engineers, QA tester, product owners, and UX designer. Unfortunately the rest of my team had little interest in putting it into place where I work.
Robert C. Martin, Clean Architecture. This book was a delightful read. Uncle Bob weaved practical advice together with stories from his past that served both to illustrate his points and to entertain. While I don't agree with every word in the book (e.g. Screaming Architecture), I still recommend it to every Senior+ Software Engineer.
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Aside from its amazing content, this book has some of the best typesetting I've ever seen. I sought out a font that is a match (or near-match) and reverse-engineered the letter spacing, line height, heading font sizes, etc. Its content was great too, but I was glad to have read Vaughn Vernon's DDDD first.
Vaughn Vernon, Domain-Driven Design Distilled. This book followed up Shore's work in our book club at work. Everybody on the team really liked what they read, but nobody felt like they had actionable insights. So the engineers went on to read Vernon's IDDD, and the non-engineers read Adzic's IM and Patton's USM.
Vaughn Vernon, Implementing Domain-Driven Design. I read this book with a book club at work. While Evans's work was well-grounded in theory and left a lot of interpretation in the patterns behind DDD, Vernon is a practical, nuts-and-bolts DIY guide to one approach to DDD. Luckily, these tactics resonated with my team and our codebase has seen marked improvements in the past few months. I'm looking forward to our process catching up so we can do more than "DDD Lite."
Jeff Patton, User Story Mapping. This book was fun, practical, and completely outside any way I'd ever worked. It also helped me understand exactly why I've failed every time I tried to make my own SaaS startup on nights and weekends.
Gojko Adzic, Impact Mapping. This book was basically a pamphlet. The process seems...good? But since I'm no longer in a role with the influence or authority to recommend product direction, I doubt I'll get much use out of this for a while.
Tanya Reilly, The Staff Engineer's Path. This book wants to follow in the footsteps of Camille Fournier's The Manager's Path, but it seemed less specific and useful as a roadmap. Perhaps that's because of how different "Staff Engineer" is from company to company, at least when compared to the roles covered by Fournier. But it did help me earn my promotion to* Staff Engineer, so it was clearly worth reading.
Tamar Rosier, Your Brain's Not Broken. This book was the second I read after I got diagnosed with adult ADHD. I appreciated that it helped me de-stigmatize, because I harbored some bummer feelings when I realized no actually I didn't grow out of it. It also helped me reflect on my habits of action, and see them in a new light. I was surprised to see how much of my anger and frustration in life was a coping mechanism to help me get things done. I've had a much calmer life since recognizing that.
Alexander Tarlinder, Developer Testing. I'm not quite finished with this book, but I'll be done by the end of the year. It's been a great overview of automated testing from the perspective of a programmer. It helped refresh my memory on things I knew but forgot. It filled gaps that I had in my baseline knowledge. It corrected things I "knew" but was slightly incorrect about. I now recommend this to any programmer, whether or not they've got a habit of testing.
Austin Kleon's trilogy: Steal Like An Artist, Show Your Work, Keep Going. These books were cute, full of incredibly quotable passages, and fun to read. I didn't spend enough time on them, though. A lot of the lessons I thought I'd learned left my brain like water through a sieve.
Kent Beck, Tidy First?. This book helped me understand the economics of software through a new light. That was important to me, because during the time I spent as a Director of Software Engineering I was not given a budget and asked to manage the department's expenses.
Antonio Cangiano, Technical Blogging, 2nd Edition. This book convinced me to start a blog. It was going really well, and then I shrank back from it due to fear of vulnerability. Since I got over those fears and started blogging again, it's been a lot of fun again. I incorporated what would've been tweets into the blog (as "quick posts") in addition to my longer-form, less-ephemeral content (as "articles"). Writing has been a great way to solidify what I've learned and distill my opinions. Heck, I should migrate this comment to my blog.
I also read other books (especially on my journey to becoming a magician), but these were the ones I thought Hacker News might be most interested in.
5th: https://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-e...
6th: https://pragprog.com/titles/ruby6/programming-ruby-4-6th-edi...
For a timeline-oriented reference of changes, check out https://rubyreferences.github.io/rubychanges/ and its individual pages.
For example, I've used LLMs to write ~1600 lines of Rust in the past few days. I'm having it make Ratatui bindings for Ruby. I haven't ever learned Rust, but I can read C-like languages so I kinda understand what's happening. I could tell when it needed to be modularized. I have a sneaking suspicion most of the Rust tests it's written are testing Ratatui, rather than testing its own bindings. But I've had the LLM cover the functionality in Ruby tests, a language I do know. So I've felt comfortable enough to ship it.
> Fourth edition
> Programming in Lua
> by Roberto Ierusalimschy
> Lua.org, August 2016
> The fourth edition updates the book to Lua 5.3