frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Al Lowe on model trains, funny deaths and working with Disney

https://spillhistorie.no/2026/02/06/interview-with-sierra-veteran-al-lowe/
50•thelok•3h ago•6 comments

Hoot: Scheme on WebAssembly

https://www.spritely.institute/hoot/
115•AlexeyBrin•6h ago•20 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
811•klaussilveira•21h ago•246 comments

Stories from 25 Years of Software Development

https://susam.net/twenty-five-years-of-computing.html
49•vinhnx•4h ago•7 comments

The AI boom is causing shortages everywhere else

https://www.washingtonpost.com/technology/2026/02/07/ai-spending-economy-shortages/
91•1vuio0pswjnm7•7h ago•102 comments

Reinforcement Learning from Human Feedback

https://rlhfbook.com/
72•onurkanbkrc•6h ago•5 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
1053•xnx•1d ago•600 comments

Start all of your commands with a comma (2009)

https://rhodesmill.org/brandon/2009/commands-with-comma/
470•theblazehen•2d ago•173 comments

U.S. Jobs Disappear at Fastest January Pace Since Great Recession

https://www.forbes.com/sites/mikestunson/2026/02/05/us-jobs-disappear-at-fastest-january-pace-sin...
44•alephnerd•1h ago•14 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
196•jesperordrup•11h ago•67 comments

Selection Rather Than Prediction

https://voratiq.com/blog/selection-rather-than-prediction/
8•languid-photic•3d ago•1 comments

Speed up responses with fast mode

https://code.claude.com/docs/en/fast-mode
9•surprisetalk•1h ago•2 comments

France's homegrown open source online office suite

https://github.com/suitenumerique
536•nar001•5h ago•248 comments

Coding agents have replaced every framework I used

https://blog.alaindichiappari.dev/p/software-engineering-is-back
204•alainrk•6h ago•310 comments

A Fresh Look at IBM 3270 Information Display System

https://www.rs-online.com/designspark/a-fresh-look-at-ibm-3270-information-display-system
33•rbanffy•4d ago•6 comments

72M Points of Interest

https://tech.marksblogg.com/overture-places-pois.html
26•marklit•5d ago•1 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
110•videotopia•4d ago•30 comments

Software factories and the agentic moment

https://factory.strongdm.ai/
63•mellosouls•4h ago•68 comments

Where did all the starships go?

https://www.datawrapper.de/blog/science-fiction-decline
67•speckx•4d ago•71 comments

Show HN: Kappal – CLI to Run Docker Compose YML on Kubernetes for Local Dev

https://github.com/sandys/kappal
21•sandGorgon•2d ago•11 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
271•isitcontent•21h ago•36 comments

Learning from context is harder than we thought

https://hy.tencent.com/research/100025?langVersion=en
199•limoce•4d ago•110 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
284•dmpetrov•21h ago•151 comments

Making geo joins faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
155•matheusalmeida•2d ago•48 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
553•todsacerdoti•1d ago•267 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
424•ostacke•1d ago•110 comments

Ga68, a GNU Algol 68 Compiler

https://fosdem.org/2026/schedule/event/PEXRTN-ga68-intro/
41•matt_d•4d ago•16 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
348•eljojo•1d ago•214 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
466•lstoll•1d ago•308 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
367•vecti•23h ago•167 comments
Open in hackernews

Launch HN: BitBoard (YC X25) – AI agents for healthcare back-offices

63•arcb•8mo ago
Hi HN! We’re Connor and Ambar, and we’re working on BitBoard (https://bitboard.work). We build AI agents that handle repetitive administrative tasks in healthcare clinics like filling out intake forms, prepping charts, or managing referrals.

We were early employees at Forward, which provided primary care across the US. To scale this, we relied on thousands of remote contractors to do repetitive administrative work like reconciling patient records, and scheduling follow-ups based on care plans. It was a huge bottleneck—expensive, error-prone, and always pulling attention away from clinical care. Our software solutions were always too brittle, never managing to handle the variance of clinical data we oversaw.

AI, when applied well, is capable of performing a lot of the tasks we manually did. So we decided to take another crack at the problem by building today what we would have liked to have back then, and to help clinics use it.

Clinics send us their SOPs (Standard Operating Procedures—for example, “prep a patient chart from these records before a visit”), and we turn them into AI agents that do the work. These agents act like remote contractors: they log into EHRs, navigate internal tools, and do the work in the background. Unlike classical RPA, we build in verification and deterministic checks, so customers can confirm it was done right. Unlike low-code tools, there’s nothing new to learn. Customers don’t have to touch a UI or maintain logic. They just hand us the task, and we do it. Clinicians don’t want more screens! They erode attention and cause weird bottlenecks in operations because someone has to drive them. Our product is built to address this.

Here’s a demo video: https://www.youtube.com/watch?v=t_tQ0fYo85g. We’re not self-serve yet, but we deploy with customers in days after onboarding them. We’re working on speeding that up.

One of our early customers is a fast-growing obesity medicine group. Their MAs were spending 15 to 20 minutes per patient just entering intake form data into the EHR. That one task was taking up 30% of their MA time. We took it over in a week. It’s now fully automated, and they’ve cleared the backlog and sped up visits.

A few technical problems are specifically relevant to building healthcare agents:

- Unreliable interfaces: many EHRs and clinic tools don’t follow modern web standards, making automation brittle. We’ve forked browser-use to solve some of these challenges. We’re working on analogous infrastructure to let agents operate on desktops and across a wide range of APIs.

- Verification: in healthcare, tasks need to be provably correct. We embed deterministic checks into each workflow so agents can confirm the task was completed as expected and the output is accurate.

- Workflow generation: clinic SOPs are written in natural language and vary widely, yet still describe the actual process that works for clinics.

We charge per task, based on complexity. We’re HIPAA compliant, audit-logged, and operate in a zero-retention environment unless auditing requires otherwise.

A meaningful part is building trust in a high-stakes environment like healthcare. Part of that is making the product reliable. But another educational part is learning how to introduce a new concept like “agents” to clinics. We’re working on the right ways to describe them, to onboard them, to measure them. Endearingly, one of our customers’ agents is named “Robert Ott”, and they refer to him by name in their weekly updates like he’s a member of the team :) We’re learning a lot and have a long way to go.

We’d love to meet other folks who 1. work in medical groups or health systems and want to offload repetitive work, and 2. are building in this space and want to trade notes. We’re happy to share everything we’ve learned so far.

And this is a big space, with a lot of learnings from personal stories, from clinicians, technologists, administrators, and more. What do you make of it? We’d love to hear from you.

Comments

candiddevmike•8mo ago
> we build in verification and deterministic checks, so customers can confirm it was done right

I didn't see this in your demo, how is this being implemented? You're entering fairly important information into EHRs like allergies and medications, that's more than just high-stakes, that's medical malpractice territory. I think you folks are really pushing the limits of the FDA's medical device exemptions for administrative work here. Are you working with the FDA on any kind of AI medical device certification?

What EHRs do you integrate with?

arcb•8mo ago
Great questions. You're right that this is a high-stakes domain. Today, we only perform data entry in cases where we can deterministically verify that the information was correctly entered. Otherwise, we fail the task and flag it to the team. Re how - in the data entry case, we compare our source and destination data. For example, a JSON entry in our source must be present, without transformation, in the appropriate section of the EHR, verified by OCR. I'm taking a note to add this to our video. We also wouldn't take on anything close to diagnosis or treatment

We're also not operating autonomously: 100% of our outputs are reviewed by the clinical team shortly after entry, as part of their regular process. That feedback loop is essential, both for safety and for evolving the system responsibly.

Amongst EHRs we currently work with Athena, though we do a lot of work on isolated file stores that our customers create for us.

ljm•8mo ago
How do you deterministically verify that information was correctly entered?

Is it just

  validates :email, format: :email
In Rails?
arcb•8mo ago
It depends on the source and destination. The trickiest case is when we're using browser agents for data entry. We can use the fact that we focus on repetitive tasks to our advantage - we know what sections of UI we need to check, and for what data. We can verify correctness by re-extracting data from the destination UI (via the DOM or OCR) and checking:

That all expected fields were entered correctly.

That no unexpected or extraneous data was added.

When we have access to a direct data source (like an API or file store), verification is simpler — we can do deterministic checks and directly confirm the values.

We're also building a validation library for common field types (dates, contact info, etc.) to enforce constraints and avoid propagating unverifiable or out-of-range values.

candiddevmike•8mo ago
If you have an API, why are you using browser agents?
arcb•8mo ago
We don't use browser agents if an when we have an API - we prefer the strongest data types we can access. It comes down to what our customers can work with. Some of them are fairly technical (have an IT team), and some aren't (have a legacy portal and operate on spreadsheets / paper).
noleary•8mo ago
You mentioned your early customer in obesity medicine.

Are there specific kinds of clinics that are an especially good fit for you? Are you seeing any patterns in the kinds of clinics that are relatively eager to adopt an AI product like yours?

I don't have any feedback on what you're up to, I just think it's interesting!

arcb•8mo ago
Thanks! From our side, we’re currently focused on specialty and multi-specialty groups. For example, obesity medicine, cardiology, pathology centers, radiology clinics... These groups tend to have repeatable workflows and a lot of operational toil. That makes them a good fit for automation. Even modest time savings let clinicians go deeper on casework, or see more cases. We're also working with smaller and medium-sized groups (think 10 to 100 doctors), since it helps us sit directly with clinicians and get high-quality feedback.

Compared to 3 or 4 years ago, clinicians are much more open to AI. They've heard of ChatGPT or ambient scribes, and they often come to us with specific ideas of what they want AI to solve. Talking to them is one of my favorite parts of the job.

That said, we also hear a lot of of requests from groups that we have to turn down. Sometimes we can't guarantee success, or the product just isn’t ready for that use case. As an example, a ton of clinical interfaces only work on desktops, which we'd like to support but don't yet. We're hoping to grow into those over time.

ahstilde•8mo ago
very cool! What's the biggest thing you learned from Forward that you're applying here?
arcb•8mo ago
Thank you! One of the big ones is that clinicians don't want more screens; they're already overloaded. So we're succeeding if we're invisible and yet effective for our customers. We're not dogmatic here - we can see customer-facing UIs being useful for focused and necessary usecases. For example, changing their process should be something close to an email or a chat with their agent, but not a complex process builder that they have manage runtime complexity in.

Another is that once you free up clinician time, they will quickly find higher-leverage tasks. It shows how overloaded the system is, and that there's pent-up demand to make it better.

MK_Dev•8mo ago
This is a pretty cool idea and implementation. Any more details on the tech stack you guys are using (besides `browser-use`)?
arcb•8mo ago
Thank you! We have a fork of browser-use that lets us hand hold web agents since we know our tasks are repetitive. We can cache expected paths and fire alerts if we go off the rails. We'd love to contribute it back at some point, mainly a question of bandwidth.

We're evaluating Cua (https://www.ycombinator.com/companies/cua) to containerize our agents; am a fan so far. We're also putting Computer Use agents from (OAI and Anthropic) to the test. Many legacy ERPs don't run in the browser and we have to meet them there. I think we're a few months away from things working reliably and efficiently.

We're evaluating several of the top models (both open and closed) for browser navigation (claude's winning atm) and PDF extraction. Since we're performing repetitive tasks, the goal is make our workflows RL-able. Being able to rely on OSS models will help a lot here.

We're building our own data sets and evaluations for many of the subtasks. We're using openai's evals (https://github.com/openai/evals) as a framework to guide our own tooling.

Apart from that, we write in Typescript, Python, and Golang. We use Postgres for persistence (nothing fancy here). We host on AWS, and might go on premises for some customers. We plan on investing a lot into our workflow system as the backbone of our product.

I prefer open source when possible. Everything's new and early, and many things require source changes that others might not be able to prioritize.

Edit - one thing I'd love to find a good solution for is reliably extracting handwriting from PDF documents. Clinicians have to do this a ton to keep the trains running on time, and being able to digitize that knowledge on the go will be huge.

Very open to ideas here. We're seeing great tools and products come up by the day, including from our own YC batch.

tjsk•7mo ago
what made you fork browser-use? what were the missing bits? your use case sounds similar to what they're trying with their new workflow-use repo (I am not affiliated with them, just curious)
arcb•7mo ago
It's a great repo! We had issues with iframes and framesets (which are old DOM tags) we had to write custom code for. Some DOMs need annotation to provide meaning to an LLM (for example, a button is clearly an "add demographics" button to the human eye, but is ambiguous in the DOM (ul contains li...). Some bottlenecks in navigation required manual attention. We keep those to a minimum. I think the future is being able to progress from highly deterministic JS code, to more agentic LLM-driven decisions. One does need to be able to control this for performance, cost, and accuracy. And yes we have some overlap with workflow-use's direction, but I hope that more such OSS methods gain popularity! It'd simply mean we can go after higher value and more complex clinical tasks!
tjsk•7mo ago
Did you consider working around those using the vision models vs DOM parsing? Was cost/latency the bottleneck? Seems like the agentic future you describe would need more vision based parsing
arcb•7mo ago
I believe we will at some point. All question of the right need coming up. Text OCR has gotten really good, and if you think of it from a UI perspective, the only real contract is that a screen will show text that's representative of the information entered. The DOM is useful but is a changeable contract!
terrib1e•8mo ago
Are you hiring? I currently work at a large organization that administers govt contracts including the health marketplaces, so I have some insight into this stuff.
arcb•8mo ago
We're looking to hire our first few engineers in the next few months, and we would love to talk to anyone who has an interest in working in this domain! If you'd like to talk more we're at founders at bitboard.work and are fast to respond.
SuperNinKenDo•8mo ago
I wish you a very be on the receiving end of your "services" and their consequences.
Mashimo•8mo ago
Oh wow, I work in with Hospital software and we have APIs for referrals (from general practitioner). Thank god.

What we currently are looking at is scheduling of staff, because somehow that involves different software (dr. vs nurse), and the staff builds a spreadsheet, and then enter it into other software. Totally whack how much time and effort they spend on that.

arcb•8mo ago
I hear you. We constantly think of the value of clinicians' time. What could they be doing if they didn't have to do high-volume data entry. In one of our customers' cases, they instantly started helping doctors with responding to patients directly.
shashanoid•8mo ago
Bruh did I see browser mcp logo
arcb•8mo ago
You might have seen this OSS logo in one of our videos: https://lucide.dev/icons/bot
beingalikhan•8mo ago
how are you guys handling HIPAA compliance for AI Agents? how is it that data in motion is secure?
mikeqq2024•8mo ago
same question for HIPAA compliance
arcb•8mo ago
Great question. In the web agent case, we solely use HTTPS, and only between resources we either directly control (our servers), or whitelisted customer websites where we connect on HTTPS. An HTTP connection would fail the call stack, as would visiting a non-whitelisted link. A lot of our work happens away from the browser (in APIs and data stores), where we encrypt at rest and in motion.
sibeliuss•8mo ago
Coming from a family of medical professionals I can now go back and tell them: just wait, the future looks bright.

This is one of the most grueling, labor intensive, boring, error prone, hate my job areas possible. It makes perfect sense for agents to perform these tasks, but as with everything else there will be a labor impact.

arcb•8mo ago
We hope to be part of that brighter future! On the labor impact front, what we're seeing is that there is so much pent up demand for care, that any time we free up staff, they enable more throughput or more depth on casework. I hope we create more potential for humans to improve care because of our work.
sibeliuss•8mo ago
This will certainly be the case, and the promise of this tech. Thanks for taking on this space.