Here are five quick software development in healthcare tips from our panelists: David Pace, Executive Director at Merck Research Labs IT Enablement and User Experience, thoughtbot Development Team Lead Clarissa Borges and thoughtbot Principal Developer Joël Quenneville.

1. Plan now for third-party vendor outages later

Your healthcare software probably depends on at least one third-party vendor, but when that data source goes down, you don’t have to completely disappoint users. For a recent project, Joël and his teammates worked on deploying a dual track for users. An external third-party aggregator provided high-fidelity data on health insurance plans, but if it was down, the software was able to serve lower-fidelity information from a smaller local data set.

2. Think about “AI for developers” differently from “AI in the product”

Joël also recommends thinking about your AI usage as two different risk profiles. The first one needs less scrutiny: AI tools that developers run locally to help them write code, ideate or solve problems. But the second has a higher risk profile and deserves to be locked down much more: Any AI that’s embedded in the product and touches customer data. This classification shorthand can help you quickly decide where to spend your security time.

3. Automate infrastructure compliance between audits

Staying SOC 2 compliant is critical for some projects, but it’s easy to slip out of compliance with something like a cluster upgrade in Kubernetes. Unless you conduct a tedious audit, you’re likely to miss that compliance misstep. It’s why Clarissa uses a compliance monitoring service called Vanta that continuously audits data and infrastructure against compliance. It doesn’t cover every single compliance issue, but it provides a large safety net.

4. Create an AI agent to find security vulnerabilities

Joël built a simple penetration testing agent that scans code, creates hypotheses for potential vectors of attack then writes them up as actual attacks in a test file. Next the agent executes the test file and reports on what went wrong. You end up with a vulnerability report and test file where everything that’s a potential threat has a failing test. This makes it easy to hand over to a developer—or another AI agent—to address.

5. Carve out time for curiosity and experimentation

Inspired by thoughtbot’s investment time, David Pace at Merck asks everyone in his organization to set time aside for self-directed tech projects—work-related or not. His personal explorations have included an educational version of Wordle where every answer related to research IT terms. Giving your team room to experiment helps create a strong culture that nurtures curiosity, continuous learning and new ideas.

Wish you had this kind of thinking to add to your healthcare tech team every day? We’d love to help shape your next innovation project or deliver custom software development for healthcare faster. Let’s talk.

**

That means that when you dropped Node from your Rails app, you also dropped the tooling that would tell you a pinned package had fallen behind or picked up a published advisory.

importmap-update is a GitHub Action that closes that gap. It runs bin/importmap outdated and bin/importmap audit, opens pull requests for what it finds, and keeps those pull requests in sync on every run after that.

Why importmaps get left behind

An importmap-rails app records its JavaScript dependencies in config/importmap.rb. Running bin/importmap pin react resolves the package through a CDN like JSPM, downloads it into vendor/javascript, and writes a one-line pin with the version in a trailing comment:

pin "react" # @19.1.0

Your own asset pipeline serves the vendored copy from there. What lands in source control is that comment and the JavaScript file itself, so there’s no package.json and no lockfile for Dependabot to read. The information it would want is available, just somewhere else: bin/importmap outdated compares your pins against the npm registry, and bin/importmap audit checks them for known advisories.

Half of that is already wired up for you. Since Rails 7.2, new apps are generated with a .github/workflows/ci.yml that includes a scan_js job:

- name: Scan for security vulnerabilities in JavaScript dependencies
  run: bin/importmap audit

A published advisory against one of your pins will fail the build, which is the part you’d want to hear about first. It still stops at telling you, though. Someone has to look up the fixed version and pin it by hand.

Nothing runs bin/importmap outdated. Ordinary version drift stays invisible until it turns into an advisory, and by then you’re upgrading in a hurry.

Getting started

Allow GitHub Actions to create pull requests in your repository settings (Actions > General > Workflow permissions), then add a workflow:

# .github/workflows/importmap-updates.yml
name: Importmap updates
on:
  schedule:
    - cron: "0 9 * * 1"   # Mondays 09:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true

      - uses: thoughtbot/importmap-update@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

That’s the whole setup. Configuration is optional, and the defaults match what you’d probably configure anyway.

Grouping

Opening a pull request for every outdated package gets noisy fast, and rolling all of them into one pull request makes for a diff nobody enjoys reviewing. The action splits updates into security, patch, minor, and major buckets, and you choose a strategy for each one in .github/importmap-updates.yml:

version: 1

grouping:
  security: { strategy: individual }   # one PR per vulnerable package
  patch:    { strategy: grouped }      # one PR for all patch bumps
  minor:    { strategy: grouped }      # one PR for all minor bumps
  major:    { strategy: individual }   # one PR per major bump

open_pull_requests_limit: 10
labels: [dependencies, javascript, importmap]
branch_prefix: "importmap-updates"

Every field is optional. Both open_pull_requests_limit and open-pull-requests-limit work, which saves you a round of debugging if you’re copying from a Dependabot config.

Security updates are handled differently

A vulnerable package becomes a security pull request even when the fix happens to be a major version bump. The body still records the bump kind, so reviewers know to expect breaking changes before they open the diff.

Security pull requests are also exempt from open_pull_requests_limit. When the budget is tight, we fill the remaining slots with major bumps first, then minor, then patch, since the bigger bumps are the ones somebody needs to set aside time for.

What happens on the next run

An open pull request goes stale as soon as another version ships. On each run, the action brings its own pull requests back in line with what’s actually outdated: the ones whose versions have moved get updated in place, and the ones whose packages aren’t outdated anymore get closed with a comment saying why. Pull requests it didn’t open are left alone, even on a branch matching your configured prefix.

Try it in dry-run mode first

Set dry-run: "true" and the action runs end to end without side effects. It reads your importmap, builds the plan, compares it against your open pull requests, and logs every operation it would have performed. That’s worth doing on a repository whose JavaScript dependencies haven’t been looked at in a while, before it opens 10 pull requests at once.

Alternatives

Depfu is the only one I could find. It has supported import maps since 2023, it’s free for public repos, and it’s a paid hosted service for private ones. If you’d rather have one service watching your gems and your JavaScript together, it’s worth a look.

Issues and pull requests are welcome on GitHub.

LLMs have made it incredibly cheap to turn an idea into something you can use. That’s especially exciting for ideas that would have never survived the old cost of software development. Every company has things that might be useful to build someday, but probably aren’t worth putting six people on for three months just to find out.

Now you can find out for virtually nothing.

Where companies get into trouble is assuming that because AI made it cheap to discover a product, it also made it cheap to build that product well. Those are two very different problems.

My advice is to vibe code while you’re figuring out what to build. Once you know you’ve found something valuable, it’s time to decide whether the code you wrote to answer the question is really the code you want to build the answer on.

Vibe coding makes ideas cheaper to explore

One of the most expensive parts of software development has always been getting far enough into an idea to discover whether it’s any good. A new internal tool might save hundreds of hours a year, but is it worth taking developers off the core roadmap to find out? A new customer experience might open another revenue stream, but how much should you invest before a customer has actually seen it?

AI has dramatically reduced the cost of answering those questions. Someone who understands the problem can make something surprisingly sophisticated, put it in front of people, and learn from what happens. That’s not half-baked software development. That’s a better way to prototype.

I’ve written before that a prototype is not a product, it’s a conversation. Vibe coding lets a lot more people join that conversation.

The dangerous moment is when the prototype works

A bad prototype is easy to throw away. A good prototype can be much more dangerous.

It looks like software. It smells like software. It even behaves like software. People like it. And maybe someone has already started depending on it to do their job. Suddenly, throwing anything away feels wasteful. Beware of confirmation bias. People will be more likely to give you positive feedback on your idea which can create an illusion that there is more buy in or value in the prototype. We use shaping sprints to help us combat this and ensure what we build is actually what people want and need.

But a prototype is optimized for learning quickly. A production application has a different job. It needs to be secure, reliable, maintainable, accessible, observable, and able to change as the business changes. Software has always had an iceberg problem. AI just got remarkably good at generating the part above the water.

This is part of what I meant when I wrote don’t hire thoughtbot to write code. Code is becoming cheaper to produce. The judgment surrounding that code is becoming more valuable.

When should you vibe code?

Vibe code aggressively when the biggest risk is that the idea is wrong.

If you don’t know whether customers want something, whether an internal workflow makes sense, or whether a new product deserves funding, make the cheap version. Change it. Put it in front of people again. Learn what you were wrong about.

This is particularly interesting for established companies. There are probably people inside your company who understand a customer or operational problem incredibly well but have never been able to get their idea onto an engineering roadmap. Now they can make the idea tangible before asking the company to make a major investment.

Vibe coding doesn’t just make software cheaper to build. It also makes software cheaper to say no to.

When should you hire a professional team?

Start spending real money on professional product development when you have evidence that the idea deserves a real investment, but not a minute before.

That point comes sooner when the application handles sensitive data, processes money, integrates with important systems, supports a critical business process, or will be used by a significant number of customers or employees.

It comes much sooner in regulated industries. A vibe-coded healthcare prototype can be a fantastic way to test a patient experience. That doesn’t mean I want the same prototype storing protected health information next week.

Security, privacy, accessibility, auditability, permissions, and compliance aren’t things you sprinkle onto an application once people like the demo. They should influence how the application should be built in the first place.

I’ve written more about this in AI makes creating software faster, but in regulated industries, judgment matters more.

Is it cheaper to fix a vibe-coded app or rebuild it?

Over the last couple of years, we’ve been asked to evaluate a number of substantially vibe-coded applications. Some of these have been exceptionally well-written, but most have had serious gaps. So far, particularly in regulated industries, we haven’t seen a single one where fixing the existing application was clearly less work than rebuilding it properly.

That will change as the tools improve. But I also think we’re asking the wrong question.

If you spent $15,000 building a prototype that saved you from spending $200,000 building the wrong product, that was money well spent even if we throw away every line of code. The return on a prototype should be measured in what you learned, not how many lines of code you managed to keep.

A good vibe-coded application might clarify the workflows, expose bad assumptions, prove demand, or secure funding. By the time a professional team gets involved, you may know far more about what should be built than if you’d hired them on day one.

The prototype wasn’t the first version of the product. It was the research that made the first version better.

How to decide

When you’re uncertain about the idea, optimize for learning and vibe code it. Once you know the idea is valuable and the uncertainty shifts to how to make it secure, scalable, maintainable, and ready to become part of a real business, bring in experienced product designers and developers.

There is an exception if you genuinely want to become the long-term developer of the application yourself. If so, keep going and keep learning.

But if your actual job is going to be running the business, leading a product organization, practicing medicine, selling insurance, or doing anything other than becoming the developer of this application, don’t accidentally give yourself a second career because the prototype was fun and easy to make.

I want companies to vibe code more, not less. There are good ideas sitting inside companies right now that would have been irresponsible to spend $150,000 exploring a few years ago. We should explore them now.

Just don’t assume there needs to be a continuous line of code between the thing that helped you decide what to build and the thing your business ultimately depends on.

You can’t choose who you lead!

We call them Engineering Managers, Product Managers, Directors, and so on. And while these folks sometimes lead people who do a similar job, like for example, developers – in the end, they lead an individual. Their job title actually doesn’t say a lot about how you have to lead them. It doesn’t matter if you manage only designers, only developers or a combination of both. You manage people. And for that, you need people skills. Empathy. Knowledge. Experience.

Throughout your career as a manager, you will meet various kinds of people. Different age, different background, different personalities, people with different ways to learn. It’s your responsibility to figure out how to manage the individual person. How to help them grow. Surely, this can become quite challenging the more people you lead. Which is usually the reason, you start with leading only one or two. And with time and experience, more will follow.

The gender gap

According to the We need more women in STEM abstract, only 26.7% of people working in the tech sector in the UK are women. In the US, worldmetrics (see the “Gender Representation” section) shows a percentage of 25.9%. These low numbers highlight a non-irrelevant issue for leaders: they get way fewer opportunities to gain experience leading people who menstruate than people who don’t.

At the same time, the attrition rate is immense: Womenhack.com, for example, shows in the “Retention & Attrition” section, that 50% of women are leaving tech by the age of 35 and that the workplace culture is the primary reason for that. Interesting and unfortunately not surprising, or is it? Good news, it doesn’t need to stay like this. Culture can change. Leadership can change. You can change.

Workplace culture – and what PMS has to do with it

In Germany, we have the saying “Der Fisch stinkt vom Kopf her” (“A fish rots from the head down”) which is used to describe that systematic issues often start on the leadership level. But it mustn’t be issues that start at the top, it can as well be defining a positive and safe environment that originates there. And creating a safe environment might start by understanding the effect PMS has on team members.

Said effect can be quite different for each individual as symptoms of PMS and similar syndromes vary. You don’t have to remember all of them. It’s even okay if you forget that PMS stands for premenstrual syndrome when you are done reading. It’s awareness I’m after.

Depressed mood and mood swings are 2 common symptoms. Headaches, fatigue, muscle and breast pain, inability to concentrate, weight gain, a feeling of being overwhelmed and anxiety are others. There are more and intensity varies – what’s important to remember is that these symptoms appear regularly, possibly monthly, without any input from the person. It’s a condition. Not a choice.

No special treatment

Knowing about PMS doesn’t mean you have to give out special treatment. It means to be aware and to offer support. Someone who has a hard time following a meeting mentally doesn’t need to hear that they have to stay focused. Let them watch the recording at a later time if possible. Be aware that someone suffering from cramps might lie down during the day. And someone with a challenging client might need support when a difficult situation arises. Offer guidance on how to communicate when being on edge.

Learning about PMS and what it means for you as a leader can be a starting point to shift workplace culture for the better, to reduce attrition and to lead intentionally.

But recently, I’ve been working on a project where the team uses a lot of AI and the domain is very complex, so I’ve reluctantly been using it to help me understand what is happening in the app and how changes I make affect areas of the app I didn’t even know existed. As I get more and more comfortable turning to Cursor to help me get unstuck in my code, I do not like what is happening to my brain.

I keep knitting near my desk so I have a way to keep my hands busy in meetings and I’ve been picking it up while waiting for a response from Cursor sometimes. I’m currently working on a pretty complicated sweater pattern with minimal instructions that are hard to interpret. I recently stepped back to look at my work and saw the pattern had gotten wonky a few rows back and realized my first instinct was to turn to AI. This horrified me.

The whole reason I enjoy knitting is the process. I spend dozens of hours and more money than I’d like to admit on yarn to create a sweater that sometimes looks no better than a $20 one I could have gotten on Amazon. But that’s not the point! I enjoy knitting. I like using my brain and my hands and figuring out solutions to problems. It feels amazing to respond to “I like your sweater” with “THANKS I MADE IT ALL BY MYSELF”. Turning to AI when I encounter a bump in the road is the opposite of that. And to be totally honest, I have tried asking ChatGPT for help on projects before and it didn’t help at all. So why did I find myself reaching for AI to fix my sweater?

Apparently, I can’t isolate the way I solve problems at work from the rest of my life. Even if I can justify using it on my work project (a big if), I’m not a character in Severance. What I do at work affects my whole brain. Getting into the habit of handing AI tedious tasks and asking it to explain things I’m not familiar with instead of trying to figure them out myself seems to have decreased how much work I’m willing to put into hard things outside of work. How far will it creep into my life? When does asking Cursor to pass the right props into the right React components turn into outsourcing talking to my kids to ChatGPT?

I don’t have the answers to any of this, but I can be proud of something: my first instinct was to ask ChatGPT to fix my knitting, but I didn’t stop there. I paused, thought about how ChatGPT would approach the problem and how I would approach it, and decided that it was worth struggling through on my own. AI hasn’t ruined my brain yet, but I’m going to keep checking to make sure.

On October 21, we’ll be gathering at Badger & Co for an informal evening with fellow technology leaders from across Edinburgh and the wider Scottish tech community.

If you’re leading or building technology teams, working across product or engineering, or simply want to meet more people in the local tech community, we’d love to have you join us.

Join us in Edinburgh

• Date: October 21, 2026
• Location: Badger & Co, The Courtyard.
• Sign up: https://luma.com/rbilas03

We hope to see you there!