Rhainur

In my own (admittedly limited) experience, 2 employees in my company (that had no programming knowledge or experience) have vibe coded apps that simplify their daily roles. The apps basically automate a flowchart of steps where multiple people need to submit certain pieces of info and as they do, a "project" moves through stages and the employees get notified on Telegram.

The app really is just several simple forms with some if/else logic, but claude code allowed them to get the app up and running and deployed on vercel's free tier, and it's Good Enough™ to save them an hour or so each day lost in messaging and chasing up things.

I don't think anyone would ever have targeted an app for sale to them, and it would have been hard to twist some sort of flow management app and integrate it with Zapier or something to handle external api calls. With claude code they could just tell it what they wanted and solve their very niche issue. That's why I think that even though LLM coding has improved so much you might not see more software for sale - it's easier for people to just...make their own software.

Other people have mentioned "dynamic typing" as being the reason for this, but that's not actually true. The real reason is two Ruby features: `define_method` and `method_missing`.

If you have a class `Customer` with a field `roles` that is an array of strings, you can write code like this

  class Customer
    ROLES = ["superadmin", "admin", "user"]

    ROLES.each do |role|
      define_method("is_#{role}?") do
        roles.include?(role)
      end
    end
  end

In this case, I am dynamically defining 3 methods `is_superadmin?` `is_admin?` and `is_user?`. This code runs when the class is loaded by the Ruby interpreter. If you were just freshly introduced into this codebase, and you saw code using the `is_superadmin?` method, you would have no way of knowing where it's defined by simply grepping. You'd have to really dig into the code - which could be more complicated by the fact that this might not even be happening in the Customer class. It could happen in a module that the Customer class includes/extends.

The other feature is `method_missing`. Here's the same result achieved by using that instead of define_method:

  class Customer
    ROLES = ["superadmin", "admin", "user"]

    def method_missing(method_name, *args)
      if method_name.to_s =~ /^is_(\w+)\?$/ && ROLES.include?($1)
        roles.include?($1)
      else
        super
      end
    end
  end

Now what's happening is that if you try to call a method that isn't explicitly defined using `def` or the other `define_method` approach, then as a last resort before raising an error, Ruby checks "method_missing" - you can write code there to handle the situation.

These 2 features combined with modules are the reason why "Go to Definition" can be so tricky.

Personally, I avoid both define_method and method_missing in my actual code since they're almost never worth the tech debt. I have been developing in Rails happily for 15+ years and only had one or two occasions where I felt they were justified and the best approach, and that code was heavily sprinkled with comments and documentation.