The AI-Native Healthcare Software Factory in San Diego, California

01 / THE ROOM

A CIO put fourteen engineers in a room and asked them to prove it

The brief was blunt. Her organization had bought seats for an AI coding tool nine months earlier. Adoption looked excellent on the dashboard. Almost nothing built with it had reached production. Two teams had quietly stopped using it after a review found generated code nobody could explain, in a service that touched patient records.

She was not interested in another vendor demo. She wanted to know whether her own people could build something real, on their own platform, that would survive her own security review. So we ran a build-a-thon: her engineers, her repository, her constraints, our harness, three days.

By the end of day two, the thing that had changed was not the speed. It was the arguing. Her engineers had stopped debating whether the AI output was good and started debating whether the specification was right, because the harness made bad specifications fail loudly and early. That is the whole shift, compressed into seventy-two hours.

Why most engineering organizations stall after the pilot

This pattern is not anecdotal. Google’s DORA program surveyed nearly 5,000 technology professionals for its 2025 State of AI-assisted Software Development report and found adoption at roughly 90 percent, up 14 percent year over year. It also found that AI adoption correlated with higher delivery throughput and, at the same time, with increased delivery instability. The report’s central conclusion is that AI does not fix a team. It amplifies whatever the team already is.

The quality picture is sharper still. Carnegie Mellon researchers studied 807 open-source repositories that adopted an AI coding agent between January 2024 and March 2025, measured against a control group of 1,380 comparable repositories using SonarQube. Output surged in month one. By month three, velocity had returned to its prior baseline. Static analysis warnings and code complexity did not return. They stayed roughly 30 percent and 41 percent above where they started.

The most useful sentence in the Carnegie Mellon paper is not in the findings. It is in the practical implications, where the authors suggest teams adopt engineered rules that enforce rigid quality standards for agents, noting that the agents are generating code into a vacuum without institutional knowledge of what good code looks like in that specific project.

That is the entire thesis of a software factory, written by independent researchers with no product to sell. The problem is not the model. The problem is that most organizations point a powerful generator at a codebase and give it nothing to aim with.

What a software factory actually means

A software factory is a repeatable operating model for building software. It consists of standardized pipelines, reusable engineering harnesses, prebuilt accelerators, automated quality and security gates, and governance that applies to every project by default.

The contrast is with a project-based development team, which reassembles its process for each engagement. In that model, quality depends on which engineers happen to be staffed and how much time the lead has to enforce standards. In a factory model, the process is an asset that exists independently of the people running it on any given day.

The word matters here because “factory” is often heard as a synonym for commodity output. It is closer to the opposite. A factory is what makes non-negotiable standards affordable. It is why a regulated manufacturer can guarantee a tolerance on the ten-thousandth unit as confidently as the first.

The ADLC: how agents are governed on the factory floor

An agentic SDLC is a software development lifecycle in which AI agents perform substantive work across planning, coding, testing, review, deployment, and operations, while engineers set intent, own architecture, and approve outcomes. It is distinct from AI-assisted coding, where a developer directs every step and the model only suggests.

Bitcot’s implementation is the ADLC, our AI development lifecycle. It is the harness that sits between an agent’s capability and a production healthcare system.

Four planes that make agentic work safe

1. Specification before generation. Agents amplify intent, including the vague parts of it. Every unit of work starts as a structured specification with acceptance criteria, data boundaries, and architectural decisions recorded before a single token is generated. This is the single largest determinant of whether output is usable.
2. Governed context. Codebase conventions, domain constraints, security patterns, and compliance requirements live as durable, versioned context that every agent run inherits. Standards stop varying by whoever wrote the prompt that day.
3. Deterministic gates plus human judgment. Automated static analysis, security scanning, dependency policy, test coverage, and evaluation run on every change without exception. Senior engineers spend their review time on architecture, failure modes, and data boundaries, which is where human judgment is actually scarce.
4. Evidence as an output. Each increment produces traceable decisions, compliance mapping, and documentation alongside the code. In a regulated environment, code you cannot explain is code you cannot ship.

The ADLC in one view. Agents and engineers work the same nine stages in parallel lanes, constrained above by governance and producing evidence below. Nothing reaches production without passing through both.

Inside the AI-native healthcare software factory

Bitcot’s AI-native software factory turns healthcare ideas, workflows, and legacy systems into secure, intelligent, production-ready digital products. It is assembled from seven components, each of which exists so that a given class of decision does not have to be re-litigated on every engagement.

Product teams work alongside specialized AI agents across discovery, architecture, development, testing, security, compliance, deployment, and operations. The point of that arrangement is acceleration without surrendering human judgment or engineering accountability. Those two things are the product. Speed is a consequence.

What comes off the line

The factory supports the complete lifecycle of modern healthcare solutions rather than a single
product category:

• Patient and clinician applications. Web, mobile, and desktop software built for real clinical environments, including the hospital-floor conditions where a browser tab is not a viable delivery mechanism.
• EHR and ecosystem integrations. HL7 and FHIR interfaces, identity federation, device and hardware integration, and the unglamorous connective work that determines whether a product is adoptable.
• Workflow automation. Removing manual steps from intake, scheduling, documentation, prior authorization, and revenue cycle processes without removing the clinician’s ability to intervene.
• Data and intelligence platforms. Pipelines, warehouses, and semantic layers that make clinical and operational data usable for analytics and for AI, with lineage intact.
• Conversational and autonomous agents. Retrieval-grounded assistants and multi-step agents with explicit tool boundaries, human approval gates on write actions, and evaluation harnesses that run continuously.
• Regulated software systems. Products where documentation, traceability, and change control are functional requirements rather than paperwork.

Every solution is engineered with privacy, interoperability, observability, evaluation, security, resilience, and responsible AI built into the delivery system. Not added after development, when adding them costs ten times more and works half as well.

Why healthcare raises the floor

Healthcare software has failure modes that do not exist in most software. A silent integration failure on a hospital floor is a clinical event, not a support ticket. That difference shows up
in the numbers.

IBM’s 2025 Cost of a Data Breach Report put the average healthcare breach at $7.42 million, the costliest of any industry for the fourteenth consecutive year, with containment averaging 279 days. The same report found that 97 percent of AI-related breaches occurred at organizations lacking proper AI access controls, and 63 percent had no formal AI governance policy at all. Those two findings belong together. Ungoverned AI adoption is now a measurable line item in breach cost.

The regulatory direction reinforces it. The proposed HIPAA Security Rule update, published as a Notice of Proposed Rulemaking in January 2025, would be the first material overhaul since 2013, eliminating the “addressable” category and making specifications such as encryption and multi-factor authentication mandatory. It remains proposed, with its final form and timing uncertain. That is precisely why it is worth building toward now: enforcement priorities have already shifted toward the controls it describes, and most of them are simply what defensible security looks like in 2026 regardless of the rulemaking outcome.

For teams whose software touches device or clinical decision territory, the FDA’s January 2025 draft guidance on AI-enabled device software functions applies a total product lifecycle
approach, tying design, development, maintenance, and documentation together across 67 pages. Its practical message for engineering leaders is that documentation is not a submission artifact produced at the end. It is a property of how the system was built.

There is one more constraint that shapes every healthcare engagement, and it is the reason we built for brownfield rather than greenfield. Black Book Research found that 85 percent of surveyed rural and critical access hospitals considered the total cost of ownership of their legacy EHR unsustainable, and yet this did not produce a wave of replacements. The same research identified the cost of initial and ongoing integration, along with vendor unwillingness and delay, as the single biggest barrier to interoperability.

Replacement is not on the table for most organizations. The work is almost always integration into something old, documented poorly, and running right now. A factory that only performs on clean codebases is a factory that does not perform in healthcare.

AI build-a-thons: how CTOs and CIOs lift their own teams

An AI build-a-thon is a structured working session in which a client’s own engineers and product managers ship a real, governed increment of their real codebase using an agentic development harness. The distinction from a hackathon is the whole point. A hackathon produces a prototype that gets admired and deleted. A build-a-thon produces merged work and leaves behind the machinery to keep producing it.

We run them because we kept meeting the same executive. Their team was not short on enthusiasm or tool licenses. They were short on a defensible way to use what they already had.
Buying more capability does not fix that. Installing the harness does.

What actually happens

1. Pre-work. We select a real backlog item with genuine constraints, not a toy. Repository access, environment, and data boundaries are agreed in advance so day one is not spent on credentials.
2. Harness installation. The team’s own standards, architecture patterns, and compliance requirements get written into versioned context files that agents inherit. This is usually the first time an organization has articulated its standards in a form anything can read, including new human hires.
3. Specification drills. Engineers practice writing specification contracts and watch agents fail predictably against vague ones. This is the fastest unlearning mechanism we have found.
4. Governed build. Teams build in the agent lane and review in the human lane, with automated gates running the entire time. Failures are the curriculum.
5. Review and evidence. Work goes through the client’s real review process, with the documentation and decision records the ADLC produced. The security or compliance stakeholder is in the room for this, deliberately.
6. Handover. The team keeps the harness, the standards files, the gate configuration, and a written path for extending them. We are explicitly trying to make the second build-a-thon unnecessary.

What changes for the executive sponsor

The outcome a CTO or CIO cares about is rarely the feature that shipped. It is the four things that become true afterward:

• Standards become inspectable. Engineering conventions move out of tribal memory and into versioned files, which benefits human onboarding as much as agent output.
• Review capacity stops being the ceiling. Deterministic gates absorb the mechanical review load so senior engineers can spend judgment where judgment is scarce.
• The compliance conversation moves upstream. Security and compliance stakeholders see evidence continuously instead of receiving a package at the end and being asked to bless it.
• The team owns the capability. No dependency is created on the partner who ran the session. That is the difference between enablement and vendor lock-in, and executives can tell which one they bought within a quarter.

Why this got built in San Diego

San Diego is one of the few places where life sciences, medical device manufacturing, defense grade software, and a serious digital health sector share the same talent pool. The practical consequence is that engineers here tend to have already worked somewhere that treated documentation, traceability, and verification as normal engineering rather than bureaucracy.

That matters more than it sounds. The hardest part of running an agentic SDLC in a regulated domain is cultural. Teams that have never worked under audit tend to experience quality gates as friction. Teams that came up through device or clinical software experience them as the normal cost of shipping something that touches a person.

Bitcot is headquartered in San Diego and works with healthcare product companies, health systems, and digital health teams across the United States. Build-a-thons run on site or distributed, though the on-site version consistently produces better arguments.

Why this is not vibe coding

Vibe coding means prompting a model in natural language and shipping the output largely as written. It is genuinely good at what it is for: prototypes, internal tools, throwaway exploration, proving an interaction is worth building properly. We use it ourselves for exactly those things.

The confusion happens because vibe coding and AI-native development share a surface trait. In both, AI generates most of the code. The difference is entirely in what surrounds the generation: the specification contract, the governed context, the deterministic gates, the architecture review, the evaluation, the compliance-mapped evidence.

Vibe coding optimizes for time to demo. AI-native development optimizes for whether the system is still safe, auditable, and maintainable long after the demo is over. For a platform that hospital staff depend on during a shift, only the second question has ever mattered.

This is also why the honest framing of an AI-native factory is not “less engineering.” It is more engineering, redirected. AI carries the weight that used to consume months of a senior engineer’s time, which frees that engineer to spend their attention on architecture, failure modes, clinical risk, and data boundaries. Those were always the parts that determined whether healthcare software was any good. They were just chronically underfunded, because the typing took so long.