Freider Torres

AI Engineer

I design and evaluate systems built on language models: what the code decides, what the model decides, and how the data shows me when the model is wrong.

I evaluate against real decisions: I check a model's scores against what people actually decided, and I set the pass bar before a run, not after.

(Profile)

I work across the whole system around the model: the data it receives, the application that uses it and the code that decides what to do with its answer.

I've spent three years shipping production software and, since 2025, building language models into automation workflows. That's where my habits come from: diagnosing failures from the logs, adding retries at every integration point and migrating data without losing a record.

I own the systems I build end to end and set the rules they ship under: what the model may decide, what gets measured and what blocks a release. I start from a problem that isn't defined yet, agree with the decision-maker on what counts as solved, and keep it running in production.

Read the blog

Where I've worked.

AI Engineer

Outrix Intelligence August 2026 – Present

Full-stack Developer

Boson Planning May 2025 – August 2026

Freelance Full-stack Developer

October 2023 – August 2026

(Principles)

Look at the data first

Before I change a prompt or a model, I read real outputs and note where they fail. A summary metric tells you something is wrong; a failure you've read tells you what to fix.

Simple breaks less

If the steps are known, I write them in code. The model comes in only where rules break, and an agent only where the path can't be planned. Every extra layer has to pay for itself.

Validate, don't guess

Every model response comes back in a defined shape and is validated before it touches anything. Whatever doesn't fit is rejected and logged: a system that silently guesses is worse than one that fails in plain sight.

Measure before you change

A change to the prompt, the model or the data gets tested on real cases before it ships. A small comparison is enough to make a call, not to settle the question, so the rule I work toward is a set of cases that grows with the system and that every change runs against. Where no cases exist yet, a person approves every output. Code my agents write goes through the same checks and my review.

MODELS & AGENTS

Claude

Gemini

Claude Code

MCP

BACKEND & DATA

Python

Pydantic

FastAPI

TypeScript

PostgreSQL

Supabase

WORKFLOWS & DELIVERY

n8n

Docker

GitHub Actions

Write to me about a failure your model won't stop repeating, or one of the principles above you'd argue with. Those are the emails I answer first.

Contact

Email me at

Click to copyOpen in your mail app ↗

✓ Copied to clipboard