I hated getting paged late at night when I was on-call. So around two months ago, I built an AI assistant to do on-call for me, and posted it to Reddit (https://redd.it/1jibmtc). Turns out everyone hates getting paged - 300+ devs messaged me about it!After a ton of work, it’s now ready to use. It’s called… well… OnCall, and it’s your AI on-call assistant.OnCall solves errors thrown from...
The lazy architect (OpenAI’s o3). o3 is incredibly lazy at writing code, but very good at planning. Will happily read tens of files and do deep analysis, but often struggles in scenarios where it needs to edit more than one file.The over-eager child (Claude Sonnet 3.7 Thinking). Claude Sonnet is eager to just get going, man! It’s not the most careful, and in longer strings of tool calls,...
For what it's worth I pasted this into a few tokenizers and got just over 24k tokens. Seems like an enormously long manual of instructions, with a lot of very specific instructions embedded...
Everyone hates production bugs. Users get frustrated. Engineers get paged. Development gets delayed. But what if many of those bugs could be fixed automatically?Enter Paladin, a tool I built that automatically sends you a pull request to fix bugs shortly after they occur.A little over a month ago, I posted my hacky but effective AI setup for fixing production bugs to Reddit...
The reason why I never book on TaskRabbit or Thumbtack anymore is because there's legitimately an 80% chance that they don't show up. There's no penalty for not showing up or expressing higher availability and just choosing from it.
This means that every repair or home service that I consider is a simple question. Is this worth rebooking multiple times or will I just bite the bullet and try to do it myself.
I would be willing to pay around 1.5 - 2X more than I book for if I had some guarantee - financial or otherwise, that they would show up. Just the ability to construct a simple equation in my head - "is this repair worth $X" in my head without trying to manage the cost of a no-show would be huge and would have me checking the cost of much more small repairs.
As for your points: 1. Definitely. We are trying to get to feature parity ASAP with traditional methods so that our AI modules can really shine. We're building out a library right now so that scientists can put together their own pipelines.
2. We're keeping everything open at this point, and definitely see the possibility that other domains will need structured image analysis like the kind that we are building.
3. Interesting - might be a better way to phrase what we are working on.
Thanks! If you're interested in chatting, would love to get in touch. Reach out at michael at biodock dot ai.
If you mean clinical diagnostics histology - we're going to hold off a bit on that, although we're discussing some early partnerships there.
We do have lots of unlabelled data, and we're also labeling a large portion of it. We do transfer learn for all of the models we're training, and the first backbone we use is partially self-supervised. Seems to help in overall performance, but it's not a huge effect in our experience.
Maybe once we get a lot of models we can release the backbone weights for nuclear segmentation or at least a competition set of some data we've labeled. Some IP issues here though.
What kind of alternative are you looking for? Specifically one for cells, or just for biologics in general? I'm guessing you're trying to have a better base of weights to transfer off so you can train your own model?
I would say we have medium diversity in terms of images - I think unless you have a similar application right now, you'd be better off transferring off of Imagenet just due to the amount of labeled data.
I guess the point I was making was that we want to make sure we don't then use this generated or modified data in order to test other algorithms in the space and say we're better. Simply put, it would be unfair for us to make changes to perform better on a hurdle and then put other algorithms through those hurdles. But for internal use, it's definitely great!
As for correctness, we've only done mAP scores and traditional accuracy metrics so far to compare with other algorithms, but we also have our own internal metrics and a test set we're building out in-house to cover many edge cases, many of which cover some of the things you are talking about. One thing we're always trying to be sensitive of is fairness. We want to make sure that we're not biasing the test to our algorithm, which would make us look better than we are.
As for the size of data - it's definitely a tradeoff here. We're seeing more and more scientists already uploading their data to the cloud however. We even integrate with data stores like S3 already so you can hook into data you've already uploaded.
We're also looking to build out a pipeline builder - where you can process images in real-time, so this would be less painful, as well as a Dropbox-like mini tool so data would be uploaded as you acquire it.