AI Development Reality Check: Practical Lessons for Healthcare CIOs

Bill Russell Date: July 29, 25 - Transforming Healthcare, One Connection at a Time.

My Story

When I code, I don't do anything else. I don't really do email, and I barely come out of my cave. But I immerse myself in the problem, listen and learn as much as I can from as many different perspectives as I can, and I never lose sight of the goal: to produce code that can be used in production.

We run a media and events business at its core. Over the years, we've grown with systems built on top of Airtable, Google Sheets, and some cloud-based enterprise systems for ERP and CRM. We've knit all of this together on the back end with Zapier and N8N. Great for the nimble startup. We could ideate, iterate, and implement in hours. Move very fast.

But all that breaks when you grow. Architecture is a thing. Best practices and systems for data governance and data quality are essential. Automations become fragile as you hire more people and they get into systems where they can easily color outside the lines and break things.

So we're aggressively heading toward vertical integration powered by a custom application developed on an enterprise-scale database, with solid points of integration, security at its foundation, and usability as a design imperative. A single app that can pull us into the future—with architecture, automation, AI integration, and data quality.

As a thought and learning exercise, I decided to build it myself after getting quotes for hundreds of thousands of dollars. Not with a team, by myself. This is my story. This is written for the Healthcare CIO who likely won't be coding anytime soon, but they want to understand what is possible. Here is what I found.

The Hidden Costs of Low-Code for Healthcare Systems

I started with low code/no code. This was my go-to over the last decade. These tools require you to learn the tool. Many have AI built in now to help you. But in the end, you will learn the tool. Its function is to produce code. It is an intermediary to what you want: great production-ready code. You tell the tool what you want, and it produces the code.

Low code/no code platforms promise rapid development, but they come with hidden costs. You're still constrained by the platform's limitations, data models, and integration capabilities. When you need to go beyond what the platform supports—and in complex business environments, you always do—you're stuck.

AI-First Development: New Promise for Healthcare IT

In steps Cursor, Windsurf, and Claude Code. Instead of using AI to learn a tool, you're using AI to write code. Not production-ready code at first, but code nonetheless. You aren't hindered by the limitations of the low code/no code tool. It's just you and the open road.

Or at least that is the illusion at first.

You prompt. It develops. After setting up the environment, which took me a significant amount of time. It develops, but what did it develop?

This is where we come across one of my core principles in this whole thing:

"AI amplifies expertise—it doesn't create it."

Reality Check: AI Isn't Autonomous (Yet)

The tool is only as good as the person on the other end. AI is no more autonomous with coding today than it is with driving. I believe both will get there, but there's still the ambiguity of the English language that will always have to be overcome.

When you prompt an AI to "build a user management system," what do you get? Something that technically works, but probably doesn't handle edge cases, might have security vulnerabilities, and definitely doesn't align with your specific business logic. The AI doesn't understand your context, your constraints, or your quality standards.

Real-World Lessons from Building AI-Enabled Systems

Here's what actually happens when you move beyond the demos and tutorials to build production systems with AI assistance:

1. Context is King: The Power of MCP

Before diving into the technical lessons, the most important discovery: context is everything.

I now write documents for each feature I'm implementing that detail what I'm building, its interaction with the database tables, and RPCs. I give design examples and approaches in the document. I load it into context for the Cursor session, and then I start prompting.

But the real game-changer is MCP (Model Context Protocol). I utilize MCP extensively to give my sessions context, both the development environment and my AI tools. MCP gives your AI assistants access to capabilities beyond themselves. This is how Cursor can look at your tables and write and rewrite RPCs until they work.

"Context documents become living documentation"

What MCP Enables:

• Direct database schema access for AI assistants

• Real-time code repository examination

• Dynamic testing and iteration of generated code

• Integration with development tools and APIs

• Live system state awareness during development

I've seen people do this for whole systems using PRD (Product Requirements Documents) and Cursor Code, which is really cool but beyond my current abilities. I use AI to help me craft the context documents. This becomes the documentation in the end.

Why This Works:

• AI understands your specific business logic, not generic examples

• Database schema and RPC details prevent common integration mistakes

• Design patterns ensure consistency across features

• MCP enables AI to validate its own work against other code and systems

• The context document becomes living documentation that stays current

The Process:

1. Set up MCP connections to your database, GitHub, and development environment

2. Write (AI-assisted) context document for the feature

3. Load the document into the Cursor session context

4. Prompt with specific implementation requests

5. AI builds, tests, and iterates using the MCP-provided system access

6. The context document serves as the final documentation

This approach transforms AI from a generic code generator into a specialist developer who understands your specific system architecture, can validate its work in real-time, and builds according to your established patterns.

2. Database Access: Tempting but Dangerous

Don't allow AI unfettered access to your database. You will be tempted to click "always allow" as it will save you tons of time. However, I have found that I always want to be aware when AI is changing vs looking at the database.

"You will be tempted to click 'always allow' as it will save you tons of time. Don't."

AI with access to the backend database is extremely powerful and dangerous. AI has essentially become my backend developer, handling RPCs, design, SQL code, and APIs. However, it will do things to the database at times that infuriate me.

The Safeguards:

• Always review database modification requests

• Use staging environments that mirror production

• Maintain human oversight of all schema changes

• Set up MCP with read-only access when possible

• Never give AI direct write access to production systems

AI doesn't understand production constraints. It might suggest changes that work in development but break in production. It doesn't consider data migration paths, performance implications, or business continuity.

3. Multi-AI Review Process: When Development AI Gets Stuck

My Claude sessions have MCP as well, so they can have access to the same information as my development environment. It's interesting how sometimes my development AI will get stuck. I have to go back to Claude and write a more explicit context document to help it solve the problem.

How It Works:

• Development AI (Cursor) builds the initial implementation

• When it gets stuck or produces suboptimal code, switch to Claude

• Use Claude to analyze the problem and write better context documentation

• Feed improved context back to the development environment

• Sometimes use different AIs for different perspectives on the same problem

Different AI sessions or windows checking AI's work are effective. I use one AI to write code, another to review it for security issues, and a third to check for performance problems. They all have access to the same context. This catches issues that single-session development misses.

4. AI-Agnostic Tools Are Best

Find the IDE you like, and make sure it can plug into any foundation model. Don't get locked into single-vendor AI strategies—the landscape changes too quickly.

"Flexibility beats optimization for any single model."

Current coding assistants are amazing and flawed. Claude is the best coder. Cursor is still my tool of choice after trying many of them. But here's the thing: no single tool solves everything. Claude writes cleaner code, but Cursor integrates better with my development workflow. GitHub Copilot is fast but sometimes misses context.

Use tools that let you switch models easily. When one AI gets stuck on a problem, I can quickly switch to another without changing my entire development environment.

5. Design-First Development: Essential for Clinical Systems

Refactoring is quicker with AI, but you know what is even quicker? Getting the database and requirements right first, and then developing. Design first, architecture matters.

"An hour of up-front design will save you a week of redesign."

An hour of up-front design will save you a week of redesign. This classic principle becomes even more important with AI because AI can implement bad designs incredibly quickly.

The Process:

• Map out data models and relationships first

• Define API contracts and integration points

• Establish your security model up front

• Plan user experience flows

• Only then start the implementation with AI assistance

6. AI Artifacts: The Unexpected Design Partner

AI artifacts are amazing in Claude. It will build React components to demonstrate four different ways to present something in an application. Sometimes I give my development AI a picture, and sometimes I give it a code example. Both work.

AI is a great designer that understands UI/UX best practices if you push it to design with those in mind. This was a surprise. AI doesn't just write functional code—it can create genuinely good user interfaces when prompted correctly.

What Works:

• Ask Claude to create multiple design variations in artifacts

• Provide screenshots of desired patterns for AI to replicate

• Use AI-generated components as starting points for "development AI"

• Leverage AI's understanding of accessibility and responsive design principles

What This Means for Healthcare IT Leaders

The lessons from building a custom business application with AI apply directly to healthcare IT challenges:

The Architecture Imperative: Just like our startup outgrew its Zapier-and-spreadsheet architecture, healthcare organizations can't build sustainable AI-powered systems without proper foundational architecture.

The Expertise Multiplier: AI doesn't replace the need for healthcare IT expertise—it amplifies it. Organizations with strong technical leadership will build better systems faster. Those without will struggle.

The Integration Reality: Healthcare has the same integration challenges we faced in our business, multiplied by regulatory complexity. AI can help solve integration problems, but only when guided by people who understand both the technical and clinical contexts.

The Quality Imperative: In healthcare, "good enough" code can impact patient care. The multi-AI review processes and design-first approaches become even more critical when lives are on the line.

The Bottom Line for Healthcare CIOs

AI development tools represent a fundamental shift in how custom applications get built. Small, expert teams can now build systems that previously required large development organizations. But success depends on having the right expertise to guide the AI, not just the budget to pay for it.

For healthcare organizations considering custom development projects, the question isn't whether AI can help—it's whether you have the internal expertise to make AI development successful. If you do, you can build better systems faster and cheaper than ever before. If you don't, no amount of AI tooling will save you.

The future belongs to organizations that understand this distinction and invest in the human expertise that makes AI development effective.

Production note: I'm out for the month of August. Some vacation and then up to see everyone at UGM. I'll catch up with you in September.

Bill Russell is a former CIO for a 16-hospital system and founder of This Week Health and the 229 Project.