Hi HN. I built Squishling to build LLM “squishability” into services and make it expressible to beautiful Ruby code.
The idea: a Ruby class declares what it wants back (a purpose and a strict
output schema). Then the LLM can either be the whole logic of the class, or an alternative path / failover when the deterministic pathway fails:
class ShipmentUpdate
include Squishling
purpose "Normalize this carrier's tracking webhook."
output_schema do
string :status, enum: %w[in_transit out_for_delivery delivered]
string :tracking_number
end
end
ShipmentUpdate.call(carrier: "acme-freight", payload: body).squished? # =>
true
It gives engineers the ability to play with system architecture and development pathways allowing, for example, to set up a working integration now and write the code only when you can see the shape of the data after a month of usage. You can also decide if some code pathways (like a legacy data format from an old service) are no longer worth maintaining code for… and just “squish” them instead.
All open source and batteries included. Would love to know what you think.
Hi HN. I built Squishling to build LLM “squishability” into services and make it expressible to beautiful Ruby code.
The idea: a Ruby class declares what it wants back (a purpose and a strict output schema). Then the LLM can either be the whole logic of the class, or an alternative path / failover when the deterministic pathway fails:
class ShipmentUpdate include Squishling
true All open source and batteries included. Would love to know what you think.