two weeks ago I started heavily using Codex (I have 20y+ dev xp).
At first I was very enthusiastic and thought Codex is helping me multiplex myself. But you actually spend so much time trying to explain Codex the most obvious things and it gets them wrong all the time in some kind of nuanced way that in the end you spend more time doing things via Codex than by hand.
So I also dialed back Codex usage and got back to doing many more things by hand again because its just so much faster and much more predictable time-wise.
We've built a version of this on steroids - not only a registry, but also one-click mcp hosting. Would love you eyeballs if you're into mcp: https://supermachine.ai
Yeah, I do both in prod and in the lib. In the lib I even ported Anthropics streaming API to be OpenAI compatible. Will write the docs over the coming days if interested.
Assistants API use in prod used to suck because it would send full convo on each message. But last month they added an option to send truncted history so its no longer 2$ a pop thankfully. Also Grok, Haiku and Mistral is cheap
Hi HN! Started working with more text models in PyTorch, experimented with LSTMs and found most of the tutorials terribly outdated. So figured out whats the most modern best practices there (until next version of torchtext comes) and wanted to share. Do anybody use LSTMs at work or are most of the people on BERTs?
This tool saves developers from doing monkey jobs. It tries to write a passing RSpec spec off the bat. It does fancy analysis to predict the values it could feed to the API of a class.
It all started with a belief that writing unit tests is a much more deterministic process than writing app code. And it still holds true.
Running it would LOCK the class API in tests as it is. So all we would have to do is writing code, locking it, writing more code, locking it too and so on.
I am very thankful that it got featured in the Ruby Weekly today and would bake a cake for the anyone who made it happen. Thanks
It all started with a belief that writing unit tests is a much more deterministic process than writing app code. And it still holds true.
Do you think its possible to build writer in such a way so we don't have to write tests anymore?
Running it would LOCK the class API in tests as it is. So all we would have to do is writing code, locking it, writing more code, locking it too and so on.
At first I was very enthusiastic and thought Codex is helping me multiplex myself. But you actually spend so much time trying to explain Codex the most obvious things and it gets them wrong all the time in some kind of nuanced way that in the end you spend more time doing things via Codex than by hand.
So I also dialed back Codex usage and got back to doing many more things by hand again because its just so much faster and much more predictable time-wise.