Jordan Reyes
ships: retrieval systems that survive messy enterprise documents — RAG, evals, and the plumbing under them
generated 2026-07-07
claude code 41 sessions · 06-08→07-06
codex 88 sessions · 2026-01→2026-07
projects 14
summary
Jordan is a hands-on retrieval engineer: across 129 sessions and 14 projects, most of the work is Python — writing, profiling, and debugging code directly rather than delegating it. The concentration is unmistakable: RAG systems and the evaluation harnesses that keep them honest, applied to document-heavy legal and financial workflows. Depth narrows sharply outside that spine — frontend and infrastructure show up only where a project forced them, and multi-agent orchestration doesn't appear at all. This is a specialist profile, not a generalist one.
skills
deep sustained complex work: hard debugging, architecture decisions, recovery from failures
working routinely ships real work
touched brief or exploratory exposure
ai / ml
Retrieval-augmented generation (RAG) deep~30 sessions · 2026-01 → 2026-07
Designed and rebuilt chunking, hybrid retrieval, and reranking strategies across multiple corpora; diagnosed a recall collapse to an embedding-model version mismatch and re-indexed rather than papering over it with a bigger top-k; tuned retrieval for tables and footnotes in scanned documents specifically.
Eval design & measurement deep~22 sessions · 2026-01 → 2026-07
Built labeled eval sets and regression harnesses before shipping retrieval changes; caught a "helpful" prompt tweak that raised answer fluency while quietly dropping citation accuracy, and reverted it on the numbers; distinguishes offline eval from production sampling.
LLM application development deep~28 sessions · 2026-01 → 2026-07
Structured extraction with schema validation and retry-on-invalid; streaming responses with citation spans; cost and latency budgeting per request; handles provider-specific quirks directly in code.
Embeddings & vector search working~16 sessions · 2026-01 → 2026-07
Comfortable across pgvector and a dedicated vector store; reasons about index types, dimensionality, and metadata filtering; picks by workload rather than defaulting to one.
Prompt engineering working~20 sessions · 2026-01 → 2026-07
Iterates prompts against eval numbers rather than vibes; uses few-shot and structured output deliberately; treats prompt changes as versioned artifacts.
Fine-tuning touched~2 sessions · 2026-04
One exploratory pass at fine-tuning a small reranker; concluded better retrieval preprocessing was the cheaper win and stopped. No production fine-tune observed.
languages & frameworks
Python deep~50+ sessions · 2026-01 → 2026-07
Primary working language, hand-authored: async pipelines, profiling a slow ingestion path to an N+1 embedding call, careful typing and test coverage on the retrieval core. Writes the code directly and debugs from tracebacks, not by regenerating.
FastAPI working~18 sessions · 2026-01 → 2026-07
Standard service layer for retrieval APIs — dependency injection, streaming responses, background tasks for ingestion; competent, unremarkable, gets it done.
TypeScript / React touched~4 sessions · 2026-03 → 2026-06
Built a minimal query UI to demo a retrieval backend; leaned heavily on the agent for layout and styling. No evidence of independent frontend judgment.
data & infrastructure
Postgres & data modeling working~19 sessions · 2026-01 → 2026-07
Schema design for document and chunk stores; pgvector alongside relational data; reads query plans and adds indexes deliberately when ingestion slows.
Document parsing & OCR pipelines working~14 sessions · 2026-01 → 2026-07
PDF and scanned-document extraction with layout awareness; handles tables, multi-column text, and OCR noise as first-class problems rather than edge cases.
Docker & deployment working~11 sessions · 2026-01 → 2026-07
Containerizes services and ships to a managed platform; comfortable with the build-and-deploy loop, less evidence of production operations depth.
AWS touched~3 sessions · 2026-02 → 2026-05
S3 for document storage and basic container hosting; followed setup guidance closely rather than architecting independently.
domains
Legal-tech — contract and case-document retrieval, citation-grounded answeringHigh
Document processing / knowledge management (ingestion, extraction, search)High
Fintech — financial-filing analysis and structured extractionMedium
Internal developer tooling (eval dashboards, ingestion utilities)Low
ai-tooling fluency
working Uses the agent as a capable pair, not a delegate.
- Treats the agent as a fast pair programmer on code they'd write anyway — reviews diffs closely and rejects changes that don't fit the existing structure.
- Grounds AI decisions in measurement: changes proposed by the agent get run through the eval harness before they're accepted, not merged on plausibility.
- Writes tight, technical prompts with concrete file and function references; rarely under-specifies, occasionally over-constrains and has to loosen.
- Little use of subagents, parallel sessions, or automation — a mostly single-threaded, one-conversation-at-a-time workflow.
- Verification leans on the eval numbers; less evidence of catching agent mistakes that fall outside what the tests measure.
working style
- Measurement-first: builds the eval before the feature, and lets numbers settle disputes about whether a change helped.
- Narrow and deep — returns to the same retrieval-quality problems repeatedly, accumulating real judgment rather than breadth.
- Reads tracebacks and query plans directly; debugs from evidence rather than guess-and-regenerate.
- Communicates precisely and technically; comfortable in the code, less oriented toward product or stakeholder framing.
shape
specialist
A deep, narrow column rather than a T: retrieval, evals, and LLM application code in document-heavy domains, all hand-authored. The supporting skills (FastAPI, Postgres, Docker) exist to serve that column, and the profile falls off steeply outside it. This is the person you staff to make a retrieval system actually accurate — not the one you hand a greenfield product spanning frontend, infra, and orchestration.
gaps & not observed
- Frontend depth: UI work is minimal and agent-driven; no independent design or frontend architecture observed.
- Multi-agent orchestration: no subagent, workflow, or agent-coordination patterns appear at all.
- Production operations: builds and deploys, but little evidence of monitoring, incident response, or scaling under load.
- Infrastructure-as-code: no Terraform, Kubernetes, or CI/CD pipeline authoring observed.
- Breadth of language: essentially a Python practitioner; other languages appear only incidentally.
Limits of this analysis. Claude Code retains ~30 days of history, so its window is much shorter than the Codex window. Only AI-assisted work is visible — nothing here speaks to pre-AI career experience. Analysis used the practitioner's own messages, not code output. Absence of evidence is not evidence of absence.
methodology & privacy
Generated locally by analyzing AI coding session transcripts across the practitioner's project directories. Session logs were distilled to the practitioner's own messages, analyzed by parallel extraction passes, then synthesized against fixed tier definitions: deep requires sustained complex work with debugging, architecture decisions, and recovery from failures observed; working requires routine successful shipping; touched marks brief exposure. Superlatives are prohibited; every claim traces to observed sessions.
Scrubbed by design: client, employer, and personal names; identifying URLs and repositories; credentials and secrets (flagged, never reproduced); personal and sensitive material excluded entirely. Client work is described at industry level only. This file makes zero network requests.
Generated from local session evidence and reviewed by the practitioner before sharing.