Work

An agentic SDLC inside healthcare compliance

What agent infrastructure looks like when the code is regulated, the platform is fifteen years old, and the AI budget is small.

Role
Software Engineer, HRS · Rimidi platform
Stack
Django · React · Bedrock · Playwright
Status
In production

The interesting constraint was never the model.

Following HRS’s acquisition of Rimidi on 1 March 2026, I continued with the Rimidi platform. My role now spans ongoing development and releases, helping teammates build context on the system, and contributing to the architecture for bringing the two products together. I also run each sprint release across 61 production instances on AWS ECS through Jenkins.

The constraints that shape the agent work:

  • The data is PHI. Inference happens in-VPC on Bedrock. It does not leave.
  • The platform is multi-repo Django and React with a shared database and real migrations. Two tickets in flight can corrupt each other’s environments.
  • A small shared AI budget. Cost was a design constraint from day one, not something to optimize later.
  • 61 production instances. Every sprint release goes out to all of them on AWS ECS through Jenkins. Nothing experimental gets near that path without a gate in front of it.

Healthcare is where I learned to build under constraints that do not negotiate. That is a tool in the box, not a category I want to live in.

Context is the hard part, not the model.

Skills read the Jira ticket, the linked requirements, and the architectural decision records in Confluence before any code is written. Agents do not start from a blank chat with a half-remembered codebase; they start from the decision record that already exists.

Most agent failures in a large codebase aren’t reasoning failures. They’re the agent not knowing that a decision was made two years ago, in a document it never saw.

“Parallel agents” is a slide until the databases are separate.

rwt gives a ticket a matching git worktree in every repo it touches, each with its own Django stack, its own host port, its own cloned database, and a React build wired to the right checkout. Heavy infrastructure (the built image, the network, the database server) is shared with the main checkout rather than duplicated.

One ticket, one isolated stackEach ticket gets a matching git worktree in every repository, its own host port, its own cloned database and its own React build, so several agents can work in parallel without their migrations colliding. Heavy infrastructure is shared with the main checkout rather than duplicated.THREE TICKETS IN FLIGHT · ONE ENGINEERDEV-1042from the release branchapi-worktrees/DEV-1042web-worktrees/DEV-1042:8011own database cloneown Django stackown React buildDEV-1088from the release branchapi-worktrees/DEV-1088shared-lib-worktrees/DEV-1088:8012own database cloneown Django stackown React buildDEV-1103from the trunkapi-worktrees/DEV-1103(single repo):8013own database cloneown Django stackown React builda migration on one ticket cannot touch another, and this is what makes parallel agents possible at allrwt agent DEV-1042 codexrwt agent DEV-1088 clauderwt agent DEV-1103 pieach opens in its own Orca / cmux / herdr / tmux surface, already inside the right worktreeSHARED WITH THE MAIN CHECKOUT · NOT DUPLICATEDbuilt docker imagedocker networkdatabase serverredis
One ticket, one isolated stack. The unglamorous piece that makes the rest possible.

A migration on one ticket cannot touch another. That is what makes parallel agents possible at all. Three tickets can run at once without their migrations colliding, each already inside the right worktree when the harness opens.

The agents that run without me.

  • Standup notes. A scheduled task reads the day’s pull requests and commits, cross-checks them against ticket status, and writes the notes.
  • Sprint demo documents. Weekly, across the whole sprint, and it drives a browser to capture screenshots of the features that actually shipped.
  • Release preparation. On release morning, a final pass over every ticket in the sprint before the release PR goes up.
  • Branch hygiene. Post-release rebasing and syncing of the platform’s sprint branches.

None of these are chat sessions. They’re unattended jobs with real outputs that other people read.

The gate that pays for itself.

Before I mark a ticket ready for QA, an agent drives the feature in Playwright and checks it against the requirements on the ticket. It has brought down the share of my tickets that come back.

The other half is deliberate and has nothing to do with agents: when I build a feature I try to ship the small quality-of-life affordances that make it easier for QA to actually test it. That’s the part they’ve thanked me for, and it’s a better investment than any automation.

Same idea as the build gate in the factory: catch it before it costs someone else their attention.

A small budget is a design constraint, not an inconvenience.

A small shared AI budget turns context discipline and model routing from nice-to-haves into the thing the system is designed around. In practice: knowing which task classes justify a frontier model and which are mechanical enough for a cheap one, keeping context tight rather than dumping the repo into it, and being honest about which jobs don’t warrant an agent at all.

What I route where, and why, lives on /agents. That page is a dated log, not a doctrine, because the answer changes every few weeks under a quota that punishes waste.