radanskoric

It would work with most other Tool enabled LLMs. RubyLLM abstracts away the format. Some will work better than the others, depending on the provider, but almost all have tool support.

Claude is just an example. I pulled the actual payloads by looking at what is actually being sent to Claude and what it is responding. It might vary slightly for other providers. I used Clause because I already had a key ready from trying it out before.

Thanks for sharing this. The field moves so yes, it's out of date, but it's useful to see how the tools concept evolved. Especially since I wasn't paying attention at that area of development back when you wrote your article. Very interesting.

Even if you're writing a kernel, you're using a compiler. And if you're writing a compiler it's probably bootstrapped and built by itself, so you're still using a mountain of code some other people wrote. :)

Author here. You're actually right here.

I took the code from RubyLLM configuration documentation. If you're pulling in a lot of config options and some have default values then there's value in symmetry. Using fetch with nil communicates clearly "This config, unlike those others, has no default value". But in my case, that benefit is not there so I think I'll change it to your suggestion when I touch the code again.

Author here. I put the lines of code into the title to communicate to the reader that they can get a good understanding just by reading this article.

Basically, what I wanted to say was: "Here is an article on building a prototype coding agent in Ruby that explains how it works and the code is just 94 lines so you'll really be able to get a good understanding just by reading this article."

But that's a bit too long for a title. :)

Also, a big benefit of Ruby is how concise it is. Yes, there's a library under neath my code but that library is, like Ruby, also very concise. That's kind of the point.

I can see how you might have read the title as hype-ish, but that was not my intention.

Thanks, sharing my learnings on how coding agents work was my main intention with the article. Personally I was a bit surprised by how much of the "magic" is coming directly from the underlying LLM.

The shell command can run anything really. When I tested it, it asked me multiple times to run the tests and then I could see it fixing the tests in iterations. Very interesting to observe.

If I was to improve this to be a better Ruby agent (which I don't plan to do, at least not yet), I would probably try adding some Rspec/Minitest specific tools that would parse the response and present it back to the LLM in a cleaned up format.

Author here. The code I made took me 3 hours (including getting up to speed on RubyLLM). I also intentionally DIDN'T use a coding assistant to write it (although I use Windsurf in my regular work). :D

It's clearly not a full featured agent but the code is here and it's a nice starting point for a prototype: https://github.com/radanskoric/coding_agent

My best hope for it is that people will use it to experiment with their own ideas. So if you like it, please feel free to fork it. :)

Author here. The part about coding agents that wasn't clear to me was how much of the "magic" is in the underlying LLM and how much in the code around it making it into an agent.

When I realised that it's mostly in the LLM I found that a bit surprising. Also, since I'm not an AI Engineer, I was happy to realise that my "regular programming" skills would be enough if I wanted to build a coding agent.

It sounds like you were aware of that for a while now, but I and a lot of other people weren't. :)

That was my motivation for writing the article.

Interesting, can you share a bit more regarding what you tried with Gemini/MS Copilot and how it failed?

If there isn't a "real" tool out there, collecting use cases would help anyone thinking about creating it.

It's going to depend a lot on how the library is designed and how much of its functionality I need.

I am very skeptical about adopting a library because of all the reasons you listed but I am quite happy to adopt one when I see it's been stable and designed well.

What I'm looking for is a well tested library with a clean interface that doesn't look impenetrable when I look at its source. If the source looks a bit like something I might write, then at least I feel confident I can figure out an issue on my own when I hit a wall.

It's a judgement call, it just depends on where you draw the line. You're not writing ALL your code with just vanilla Typescript.

I use Ruby, I don't write all my code in vanilla Ruby.

But I definitely agree that blindly pulling in a library just because it looks like it makes your problem simpler RIGHT NOW, is a bad instinct.

Thank you again for notifying me about this. I emailed dang and he restored my account right away! :)

Some time ago I was wondering the same thing and did a little experiment: https://radanskoric.com/experiments/experiment-gradual-typin...

My take on typing and Ruby is that it makes sense in specific parts of the code where you expect to get high benefit from it.

Overall, I don't like using types for the whole project. The reason is that you end up losing some specific Ruby benefits, like being able to express the solution in a few very concise lines of dynamically typed code. Ruby is not designed to be a type friendly language and that shows when trying to use types. It works but it doesn't feel like pure Ruby anymore. It's definitely a compromise. You lose a bit of ruby expressiveness to get some type safety.

I want to emphasise that I am actually very fond of types. For example, I've been learning Rust and I really enjoy using Rust for very different reasons than I enjoy using Ruby.

I think that tools are best used in the way they were intended to be used. And for Ruby that's without types. For Rust it's definitely with types. I enjoy both very much.

In Ruby I'll use types in cases where I would actually prefer to implement the part in another language (like Rust) but using typed Ruby is going to be more maintainable than introducing a whole new language just for one section of the code.

Author here, I'm really glad it helped! Thank you for reading. :)

Author here, that's a good point. Most of my readers are Ruby developers and no one doing Ruby regularly uses the macOS Ruby. I'll throw in a simple Dockerfile for easier running.

Author here, thank you for doing this! Really nice. And yes, I was not counting empty lines, and also, no code golfing. :)

This is part 2 of my deep dive into how the upcoming Rails's Turbo 8 morphing functionality works. This is focused on idiomorph (which was developed by htmx authors and will be the default from htmx 2.0).

Turbo morphing will allow to do exactly that, exclude a section from morphing, by wrapping it in:

<div data-turbo-permanent>...</div>

I think it's not yet documented since turbo has not yet landed in a production release of Turbo but it's been merged into main, you can see it mentioned on the PR: https://github.com/hotwired/turbo/pull/1019 (Look for "Exclude sections from morphing" title in the PR description).

Author here. Yes! Turbo 8 changes are very exciting.

It hasn't been released yet but it was merged in main and I was trying it out today. I plan dig more into it and write a breakdown. I'm really interested in how it's exactly working to see what corner cases we need to watch out for. As is usual with "magical" features they're great until you run into a corner case.

Probably the best way to think about morphing is as something that gets you up and running really quickly. Then as your app matures you can replace high traffic pages with turbo frames and streams or something else. In a typical app, even when it's mature you might find that 80% of the pages are low enough on the performance requiremetns that you can just morphing and then use the development time savings to really optimise the other 20%.

I’ve spent a lot of time recently investigating if I should adopt gradual typing in my Ruby projects and I’ve summarised my research in this post where I’ve picked 5 key criteria which I’ve seen mentioned most often by people that are using gradual typing successfully.

I’m always super interested to hear about industries seemingly “neglected” by software. There are so many software product opportunities off the beaten path.

Would you mind sharing the name of that 90s software?

What makes it impossible to recreate with low/no-code tools? It sounds like a relatively standard interface over some calculations which sounds like it should fit.

Not really, you have full control over your availability. You can dial it up or down however you like. A lot of people start with hourly jobs on Toptal while keeping another gig or a day job and then switch to full time on Toptal when they're ready.

Disclaimer - I work for Toptal