mikecarroll

Hi HN! This is something I built from a crazy idea I had a few months ago, and now use all over the place in our code at Coolhand Labs.

It gives you the ability to use the probabilistic capabilities of LLM models as a fallback -- or even as a replacement -- for deterministic code.

Benefits include fewer errors and the ability to calculate tech debt in many scenarios.

Would love feedback / input!

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.

Thanks! I'd be really curious to know if other folks on HN are doing something similar.

I've been talking about this a lot the last year, and sometimes the reaction is "never heard of that" and sometimes it's "we've been doing that for a while now".

True -- there are LOTS of engineering managers who would struggle greatly with the move. They are just too far away from the details and haven't been hands-on in long enough... and don't want to be "in the weeds" anymore. (Good luck to them).

But by the same principle inverse argument is that a lot "tech leads" have the opposite problem: there's no point at which they have been out of the weeds.

That's a key skill that managers have to learn to early: what are the things you DON'T have to look at or know to be most effective. If you are reviewing every bug fix, or have to sit in on every single planning session, you will very quickly hit ceiling of your career as a manager.

I think that a great manager who has done the tech lead job and always worked a few levels above it is best positioned to succeed. But completely agree that good tech leads are very well positioned to make this move too.