Working on full stack prototyping agents that own their own Aws account (zero deploy friction). Think speed of lovable/ base44 with power of Aws services
TLDR: A startup called LymeAlert is launching a $40 at-home test (August 2026) that tells you in 15 minutes whether a tick carries Lyme disease. You grind the tick in a container, insert a chemical strip, and it changes color if Lyme bacteria are present. Founded by an MIT Sloan MBA / physician assistant who wanted to save people the $50–$450 and week-long wait of lab testing. Caveat: it only detects Lyme (not other tick-borne infections like Alpha-gal), though a multi-pathogen version is planned for next year. They're also building a smartphone app to crowdsource infected-tick locations.
Cool. Is there a simple "howto" on running this repo with training on W&B for a programmer like me who has never done model training flows? Maybe you could share the steps you took?
Hey saaaaaam . I'd love to pick your brains a bit on this. I'm working on a web3 protocol ("Legato") relating to many of these issues. Any way we can connect? (I can't find a way to DM you on HN). roy at osherove .dot [com]
Open Source Blockchain music registration & Royalties: I'm a fullstack dev working on a blockchain project (eth/polygon) for music registration and royalties on chain. Would love to work with anyone with web3 backend(solidity) / frontend(react) experience, that is passionate about disrupting the music industry - for now it will just be a big open source permissionless project. But it could end up being a nice startup with many hooks to use for profit on top: from distribution to integrations - it's a blue ocean. (email in my profile)
I believe we need to stop, as developers, to contribute our expertise to enabling such blatant surveillance that hurts much more than it helps. We're ruining our own and our children's future by writing the code that enables this, by teaching people how to write such code, how to test such code, how to deliver such code. It's on us.
I'll add after 20+ years:
- Being able to communicate ideas > Being a great technical developer
- For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule".
- Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to challenge assumptions and break through with new skills.
- TDD is a skill just like refactoring. Learn when it makes sense.
- 80% of architects in enterprise don't have the skills needed from them. including the things stated above.
- Learning the Theory of Constraints and applying it to find bottlenecks in the process, pipelines and structures of your teams/projects is one of the most useful things you can apply to become more productive.
- Learning what to measure and what not to measure, lagging vs leading indicators can help you communicate to management about what changes truly need to happen to make your team work more effectively.
- Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.
Metrics in software is a bag of issues in most companies I see. But there ARE useful ways to use metrics that actually help (software). I did a talk about this at GOTO: Lies, Damned lies, and metrics.
https://www.youtube.com/watch?v=goihWvyqRow
Where is the music being sourced from? As a music creator, how can I add my music to be visible here?
Another question (which contradicts my first question):
Aren't you helping to create another "race to the bottom" where free music always wins over paid?
That's a good way of putting it. In TOC terms, the build time becomes the new constraint to solve, but only after you solve the build frequency constraint.
True, but that type of optimization is quite moot if you're only running the build at night (i.e, that's not the first constraint to solve). In the article I mention that first get the builds to be tight one after another, then work on build times because that becomes the constraint.