I’ve always found Ruby to be way more readable, what keeps me using python is the depth of libraries is unmatched.
So unless you’re into burning tokens having AI generate untested libraries, I’d stick to using the most idiomatic tool for the problem you are tackling.
So, it's really interesting. We've started moving away from python libs because 25% OSS is out of date and another % is custom tweaks to the software help our use cases. In both scenarios it means our own fork.
And honestly it's not burning that many tokens if you've got an existing example lib to point to.
Opportunity costs: Would you rather pay 100 bucks for making more money or for your foss projects?
The same can be said of your time, but here we're talking about scale benefits due to LLMs (i.e. lots of SaaSs dying due to lots of "full featured f/oss projects").
AI is pretty good at following existing patterns in a codebase. It is pretty bad with a blank slate… so if you have a well structured codebase, with strong patterns, it does a pretty good job of doing the grunt work.
The read-only hesitation seems overcautious. If you’re genuinely using it read-only, what’s the failure mode? The tool crashes or returns bad data - same risks as the AWS CLI or console.
The “middleware layer” concern doesn’t hold up. This is just a better interface for exploring AWS resources, same as k9s is for Kubernetes. If you trust k9s (which clearly works, given how widely it’s used), the same logic applies here.
If you’re enforcing infrastructure changes through IaC, having a visual way to explore your AWS resources makes sense. The AWS console is clunky for this.
The fakes vs mocks distinction here feels like a terminology debate masking violent agreement. What you’re describing as a “fake” is just a well-designed mock. The problem isn’t mocks as a concept, it’s mocking at the wrong layer.
The rule: mock what you own, at the boundaries you control.
The chaos you describe comes from mocking infrastructure directly. Verifying “deleteUserById was called exactly once with these params” is testing implementation, not behavior. Your HashMap-backed fake tests the right thing: is the user gone after the operation? Who cares how. The issue is finding the correct layers to validate behavior, not the implementation detail of mocks or fakes… that’s like complaining a hammer smashed a hole in the wall.
Google had a good 10 year run, where the ads were genuinely useful, until the need of the public markets required and lack of competition allowed them to enshitify the experience to the current state.
I hope the same fate does not await ChatGPT but in the mean time I expect it to be a pretty good experience at first.
So unless you’re into burning tokens having AI generate untested libraries, I’d stick to using the most idiomatic tool for the problem you are tackling.
reply