Software engineering · Agent systems · Clinical operations

I build software you can inspect and verify.

I'm Jonathan De La Paz, a software builder and RN. My work includes a public AI assistant, a Rust CLI for agent skills, and tooling for testing whether an agent skill actually ran.

Explore selected work Try Ask JDP live
  • Source public repositories
  • Checks tests, CI, and releases
  • Limits stated alongside the proof

01 · Selected work

Three systems, with the proof attached

These are the projects that best show how I work. You can read the code, inspect the tests, and check the released behavior yourself.

01 Full-stack AI system

Ask JDP

A public career assistant that answers from a reviewed, server-only corpus. Its privacy rules, session ownership, retention, and abuse controls live in the code.

Problem
Give employers a useful way to ask about my work without exposing raw source documents or letting the model stretch the facts.
Decision
Keep the corpus deliberately small, then enforce privacy and claim limits in both the HTTP layer and the agent contract.
Tradeoff
The useful version needs a persistent Node service. A static page can show the interface, but it cannot run the assistant.
  • Public source
  • Live interface
  • CI verified
Read case study Try live Source
02 Rust systems tooling

Tink

A Rust CLI that installs and verifies agent skills inside a project. It records exactly where a skill came from and refuses unsafe or unexpected file trees.

Problem
Reusable agent skills can drift into hidden global state or overwrite project-owned work.
Decision
Give each kind of state a clear owner, pin the exact source revision, and stop before publishing an unsafe or changed tree.
Tradeoff
Operations are checked up front and can be retried, but Tink does not promise one transaction across every state owner or safety with concurrent writers.
  • v1.0.0 release
  • Acceptance contract
  • Four-target release CI
Read case study Release Source
03 Agent evaluation infrastructure

Tink Skills evaluation loop

A paired test that compares an agent with and without a skill, then checks whether the right model ran, the treatment saw the skill, and the saved artifacts still match the run.

Problem
A better answer does not prove that the skill caused the difference. It does not even prove that the skill ran.
Decision
Pin the harness and model, isolate the two conditions, alternate their order, record runtime exposure, and rehash the saved artifacts.
Tradeoff
When the evidence is incomplete, the report says less. It never treats one paired test as proof that a skill works everywhere.
  • Four harness adapters
  • Paired diagnostics
  • Green published-main CI
Read case study Source

02 · Engineering approach

How I make the work checkable

Different projects need different tools. My approach stays consistent: define the boundary, make failure visible, and keep the evidence close to the claim.

01

Show the proof

I link claims to the implementation, tests, commits, CI runs, releases, or a dated live check. When the proof is limited, I narrow the claim.

02

Make failure visible

Tink stops on unsafe trees. Ask JDP blocks cross-session access and known injection patterns. The evaluator refuses to score evidence it cannot validate.

03

Say what is still unknown

I do not imply adoption, causal impact, security certification, or universal model gains. The repositories do not establish those things.

03 · Background

What clinical operations taught me about software

Before I built public developer tools, I worked as a bedside RN and in Texas Medicaid prior authorization, eventually supervising the operation. That work made a few lessons hard to forget. Evidence has to survive review. Sensitive data needs a clear boundary. A fast answer is not much use if nobody can defend it.

I bring those lessons to agent systems, developer tools, and applied AI. The projects here lead with work you can inspect directly.

Working stack

  • Rust · Python · TypeScript
  • React · Hono · SQLite
  • Agent harnesses · evals · CI
  • Clinical workflow translation
Read the résumé

04 · Contact

Let's talk.

I'm looking for software engineering roles in AI systems, developer tools, or applied clinical technology.

Email Jonathan LinkedIn GitHub

Austin, Texas · Remote across the United States