Work
Most of my career has been the systems nobody gets to rewrite from scratch: the ones already in production, already carrying money, prescriptions, or public records. The job is to change them without breaking what people depend on.
Platform migrations
Moving live products between codebases, databases and frameworks while they keep shipping. Recent examples: a patient platform's move to the cloud, a data tier moved from SQL Server to PostgreSQL and three production mobile apps moved from Xamarin to .NET MAUI without a pause in releases.
Architecture with a paper trail
Decision records, spikes before commitments and designs that name what they gave up. I would rather spend a week comparing four messaging designs than a year living with the wrong one.
The questions upstream of the code
Six industries have shown me the same expensive mistakes in different clothes. Most of what I am worth happens before anyone writes code: checking what is actually true, guarding the decisions that cannot be undone cheaply and writing plans specific enough that people argue with them.
Teams that run like small companies
I manage engineers and run the full performance cycle. I have run a product team as a self-contained business inside a larger company: its own roadmap, its own releases, its own results.
AI-assisted engineering you can review
AI tools make code cheap. Trust is the scarce part. I build the practice around the tools: independent review, claims marked as checked or unchecked and evaluations that catch it when the guidance an agent follows goes wrong.
Writing
How an agent workspace works The pattern that makes AI agents reliable on a large legacy codebase: one instruction contract, generated code maps, drift gates that fail loudly, and evaluation cases. Four diagrams. The question nobody asked Six industries, one pattern: the expensive failures were decided early, by reasonable people, where a question went unasked. Three questions that keep catching them. Plausible is not checked The most common way AI-assisted work goes wrong is not bad code. It is a claim recorded before anyone checked it.About
I have built software for city governments, retirement plans, clinical research, defense research, e-commerce, and pharmacies. The first online payment system I built for the City of Tucson ran for more than a decade. Today I work on healthcare platforms that pharmacies across the country depend on.
I studied jazz before I studied software. The habits carry over: listen hard, keep time and know when to improvise.
I live in Tucson, Arizona and work remotely.
Contact
- RyanTornberg@gmail.com
- linkedin.com/in/rtornberg
- Resume
- Sent on request, by email.