Building backend systems
that think for themselves.

Every team has a tax it pays without noticing. Ours was the ceremony around shipping a change: commit, push, open the pull request, remember who should review it, ping them, wait, and — once approved — kick off the deploy. None of it is hard. All of it is interruption.

So I built an agent on top of Claude to do the ceremony for me. It commits and merges the change, opens the pull request with a sensible description, assigns the reviewer who actually owns that area, and sends the notification. When a reviewer who has the right access approves, the agent verifies that authorization and triggers the GitHub Actions deployment.

The interesting engineering wasn't the model — it was the guardrails. An agent that can deploy is an agent that can break production, so I gated the trigger behind OAuth2 and an access check, capped how many pipelines run in parallel, and made every step retry on transient failure. The model proposes; the system decides.

What surprised me most: the value wasn't really the saved minutes. It was that the deploy path became consistent. The same checks run every time, in the same order, whether it's 9am or the end of a long Friday.

"How many new patients were added this week?" is a one-sentence question and a five-minute query — if you know the schema. Most people who need the answer don't, so they ask someone who does, and that someone context-switches off whatever they were doing.

I wanted to close that gap with an agent that turns the plain-English question straight into a correct, fast query. The naive version — hand the question to a model and hope — produces SQL that looks right and quietly does a full table scan.

The fix was to stop treating it as a language problem and start treating it as a schema problem. Before the agent writes anything, it reads the relevant metadata: which columns are indexed, what the constraints are, where the primary and foreign keys live. With that context the model writes queries that respect the shape of the data instead of fighting it.

Execution gets the same care a human DBA would give it: a bounded connection pool, automatic retries, and queuing so a burst of questions doesn't knock anything over. The result is non-technical teammates self-serving answers — and me getting fewer "quick SQL favor?" messages.

Working in healthcare software, you learn quickly that the domain is the hard part. The code is tractable; the rules about what a record means, who can see it, and how it flows are not.

Getting Epic Certified on the Clarity Data Model wasn't about the credential. It was about being able to read the data the way the clinicians and analysts who depend on it do — so the services I build speak the same language as the systems they integrate with.

My takeaway for any engineer in a regulated domain: invest in understanding the data model before you optimize the queries. You can always make a correct query faster. Making a fast query correct is a different kind of expensive.