yshrestha

Innolitics | Medical Device Engineers + Physician-Scientist (MD/PhD) | REMOTE (US) | Full-Time

Innolitics builds AI/ML software for medical devices — the kind that detects ear infections, tracks metastatic cancer, and plans radiation therapy. 60+ FDA clearances. We need engineers who want their work to matter. We're a remote-only firm (since 2012) that does engineering, regulatory, and cybersecurity under one roof. Our team includes MDs, PhDs, and software engineers. Clients range from Series A startups to large device companies. We're hiring for three roles:

1. Physician-Scientist (MD/PhD) — Biostatistics & AI Software Development MD + PhD in biostatistics, bioinformatics, epidemiology, or a related quantitative field. You'll design biostatistical plans for AI validation studies (MRMC, standalone, prospective), build production-grade statistical software and data pipelines, write FDA-facing statistical sections, and analyze large clinical imaging datasets. Fluent in Python and/or R. This is not a pure research role — you'll ship code that gets FDA-cleared and deployed in clinics.

2. Senior Web/Mobile Medical Device Engineer 5+ years SWE experience. 3+ years each in web and mobile. Fluent in TypeScript and Python. You'll build medical device software and produce FDA-facing technical documentation. Cross-functional role bridging engineering and regulatory teams.

3. Medical Device Software Engineer 3+ years SWE experience. Fluent in Python, C++, or TypeScript. Heavier emphasis on software development initially; you'll grow into regulatory documentation work over time. All roles involve writing production code for medical devices, authoring documentation for FDA submissions, and working directly with clients. No prior medical device experience required — we'll teach you. Why engineers stay here:

Agentic AI tools (Claude Code, etc.) are part of our workflow. We treat them as a impact multiplier, not a threat. ~1 hour of meetings/week for ICs. Flexible hours. 2 hours every Wednesday dedicated to learning ("10x Time"). Healthcare-only revenue. No debt. Never had a layoff. We pay $300 for take-home exercises because your time has value.

Stack: Python, TypeScript, C++, R, Django, React, TensorFlow, PyTorch, scikit-learn, Qt, Terraform.

Apply: https://innolitics.com/careers/

How we work (we publish our handbook): https://innolitics.com/about/handbook/

I think the term "vibe coding" has no universally accepted definition but if you mean "coding without any prior coding experience" then the answer is no. Any leadership that know even the slightest about software know that AI tooling is on a spectrum. Vibe coding is at one end and tools like Claude Code and Cursor are on the other.

Author here.

Finally, you can ask your leadership to give you time to pay back technical debt. And AI adoption is the reason why.

I have been seeing a pattern where leadership buys Copilot/Cursor licenses and expects immediate 10x gains, but the engineering team struggles to adopt them.

The thesis of this article is that AI acts as a throughput multiplier. If your codebase is clean (SOLID, DRY, explicit interfaces), AI accelerates you. If your codebase is spaghetti or relies on "tribal knowledge" (implicit context), AI just generates bugs faster than you can fix them.

I argue that "clean code" is no longer an aesthetic preference but a hard requirement for AI enablement, because AI agents effectively have no long-term memory of your project's history.

Curious if others are seeing this friction between "AI expectations" and "Legacy Code reality"?

As a human, I can tell you that I suck at predicting exponential growth.

Location: USA

Remote: Yes

Willing to relocate: No

Technologies: PyTorch, MONAI, DICOM, HL7, medical device regulations

Resume/CV: https://www.linkedin.com/in/yujanshrestha/

Email: yshrestha@innolitics.com

I am an expert in AI/ML for medical devices. I can help with engineering and regulatory concerns.

I thought this was an interesting analysis of the potential legal frameworks around generative AI.

- Start a personal blog about software engineering principles

- Have some good code on GitHub

- Work for a startup, they are more likely to take chances on you

- Prefer working on-site if you can. Working remote is great once you have learned how to learn

Good luck with your search.

I have been using Notion AI for a couple of weeks and have found a couple of patterns / antipatterns that have worked well for my workflow.

A very simple way to improve work life balance

To learn how to stop saying "yes" to everything.

Exactly! Hey it gets the job done :)

Software is just a tall wedding cake of abstractions built on top of abstractions.

Yeah! It is interesting to try and figure out "what" the model is actually learning. It is a valid thread of scientific inquiry.

Language models can generate a Python function that does the math perfectly.

I bet you would get better results if you tweaked the prompt to say "Generate a Python program that solves X math problem" and then just ran the resulting Python script.

It does not need to be AGI to be useful.

This is an interesting account of an airliner incident caused by confusing UI and over reliance on automation.

Ah. Thanks for finding this. That makes more sense. Bacteria that are attracted to cancer cells are a fascinating concept.

It is very exciting to see another tool in the toolbox to achieve higher cancer cell therapeutic specificity.

I see. I do wonder how specific that is though. Potentially it could be toxic to other areas where vasculature could be "leaky". Like in the filtration mechanisms in the kidney.

Targeting the cancer's vascular supply is also a known anti-cancer mechanism of action (anti-angiogenics). How will this method not have the same toxicity as that one?

I may be missing something but the article does not explain how the bacteria target is actually targeting the cancer cells. Of course, if you can design an ideal universal cancer targeting mechanism, the active ingredient itself is beside the point. Did anyone else catch this?

Stopping DNA replication across the body will be fatal. This is what eventually kills with radiation toxicity.

Putt's law:

Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.

https://github.com/dwmkerr/hacker-laws#putts-law

The underlying reason for Putt's law is the finite space of the human cranium and finite hours in the day.

That is an interesting comparison. I think it highlights that engineers may need to constrain the design a few levels of abstraction lower than where they typically operate at any given time. I think performance constraints is a key motivating factor for when we need to peel back the layers of abstraction and tweak something under the hood(s).

I think another analogy is like building a skyscraper. The construction worker needs to worry about the floor below him and the floor he is working on. Everything below him is an implementation detail from his perspective.

If N is the cutting edge level of abstraction, N+1 is what research is doing, N-1 is where I like to operate at while I wait for N to stabilize.

Take a stack of AWS services for example. AWS comprehend medical is an abstraction built on a bunch of NLP building blocks. AWS health lake is an abstraction on top of AWS comprehend medical. At this point I don't care about the NLP underlying AWS comprehend but I don't want to use AWS health lake until it has a chance to stabilize and another abstraction is built on top of it.

Good observation. Code is also a Jenga tower of abstractions from High level language (Python) -> Low level language (Assembly) -> CPU microcode. No code is just yet another layer on top. The higher up you go, the more difficult it can be to debug issues, and the more locked in you will be in the infrastructure. I like to stay somewhere in the middle. Not too low such that I am wasting a bunch of time with implementation details, but not too high where I don't understand enough about the technology to fix issues. The industry, as an aggregate, is steadily and relentlessly moving up the abstraction tower.

Yes. Software engineering is just a tool. The risk to society comes when the application of the tool can cause harm. Quantifying and publishing standards to control these risk is best left to experts in the field of application to figure out and should be mostly agnostic of the underlying software engineering paradigm of the day. For example, FDA guidance on software did not need to be updated for over a decade.

"Fake it till you make it" can work well for a consumer product but look what happened when Theranos tried to apply the same paradigm to medicine. It is not software engineering at fault. It is the application.

VMs and Docker are just convenient ways to capture the "execution environment" as I referenced in my previous comment.

I think you are mixing the levels of abstraction here.

* Physicians apply the scientific method to medicine

* Electricians apply construction techniques to electrical construction

* Lawyers apply logic and reason to legal problems for a certain region

* Medical device software manufacturers apply software engineering to medical devices

The regulation should be done at the application of software engineering to X industry. The FDA for example, regulates the application of software engineering to the medical device industry.

You need two things to run a piece of code:

1) Code and execution environment 2) Compute infrastructure to run (1) on

Serverless, to me, means that (2) is abstracted away from you. You submit (1) to the serverless service (AWS Lambda for example) and the service figures out how to run it. Serverless does not mean there are not any servers. It is just something you do not need to ideally worry about. Abstractions are leaky though, and they can leak in very mysterious ways the higher up the abstraction tree you go.

That is a pretty scary side effect and why AI in medicine needs to be handled carefully, especially anything with generative capability.

I do think, however, the primary application of these newer generation of generative models will be useful for more sophisticated data augmentation. For example, a lung nodule detection AI trained on a combination of synthetic and real lung nodules may perform better than one trained on real data alone. Do you think there are any other responsible applications?

I am PM, PO, tech lead, and sometimes primary IC on several projects. I am also owner of a software consulting company so I also control budgets and customer relations. When (not if) projects go over my general strategy is to:

1) Take the pressure off the engineers by reassuring the client with one of several tools (i.e. monetary concessions, strategic scope limitation, detailed investigation, client education, etc). Stressed clients equal stressed engineers. The tension can be palpable. 2) Educate the client on the underlying reasons why we got here. 99% of the time it is because of mismanagement. It is up to management to manage client expectations vs reality and they have clearly failed to do that. It is like the situation where a physician with good rapport with the patient is less likely to sue in the event of a medical error. 3) If overtime is necessary, provide a bonus or extra PTO for overtime, even if it means the company needs to take a small financial hit. Why should engineers suffer the consequences of something that is almost always a management misstep?

I am in a unique situation because I wear so many hats at my company. Unfortunately this decision making process usually involves multiple people. The person controlling the budget is not the same one that is controlling the scope. You need to get the relevant stakeholders in a room together to figure out how to rebalance the expectation vs reality equation. Budget and/or scope are the two dials you can tweak. If this is difficult to do, it may be time to move on. Life is too short to be stressed about things you have no control over.

I have the same problem. Rather than fight it, use it as your superpower. I find it helps me write easier to understand abstractions because I can't physically hold enough in my head to understand anything more complex. Same is true for documentation!

How is 2 years flipping a house?

Full disclosure: I am the seller

I was on the fence on posting it on HN but I would have totally jumped on the rare combination of gigabit internet, land, animals, and accessory structures if I had known about it. I work remotely and always wanted the rural lifestyle. Hard to do both without crappy internet. I went through tons of bureaucracy to trench a fiber line out to the property. I have not had as much time as I would like to put into the land so I am trying it to sell it to someone else who can enjoy it.

Been working as a consultant and engineer on FDA regulated software for about 8 years now. I have seen strategies from startups to huge companies.

I have seen requirements captured in markdown files, spreadsheets, ticket management systems like Redmine, Pivotal, Jira, GitLab, Azure Devops, GitHub Issues, and home grown systems.

If I had to start a new medical device from scratch today, I would use Notion + https://github.com/innolitics/rdm to capture user needs, requirements, risks, and test cases. Let me know if there is interest and I can make some Notion templates public. I think the ability to easily edit relations without having to use IDs is nice. And the API makes it possible to dump it all to yaml, version control and generate documentation for e-signature when you need it. Add on top of that an easy place to author documentation, non-software engineer interoperability, discoverable SOPs, granular permissions, and I think you have a winning combination.

yshrestha@innolitics.com