Founder · Software Engineer · Buenos Aires, Argentina
AI agents for real-world workflows — turning messy human conversations into evidence-backed operational context.
Voice AI · Context Systems · Evals · Agent Systems
A black-box proving ground for AI agents. Adversarial scenarios, tool-use simulation, reproducible evals, pass^k, and evidence you can actually debug.
Agent Evals · Adversarial Testing · Tool Calling · Reliability
An evidence-driven decision system for founders: bounded context, versioned procedures, verified sources, independent challenge, replayable traces, and ablation-based evaluation.
TypeScript · Context Engineering · Retrieval · Evals · Provenance
Local-first privacy enforcement at the boundary between humans and AI. Detects sensitive information before it leaves the browser.
Privacy · Browser Security · Local-first · LLMs
I kept paying for tiny Mac utilities, so I started building my own. One native macOS app for the small tools I use every day.
Swift · SwiftUI · macOS · Developer Tools
I treat AI-assisted development as an engineering system, not a favorite-tool stack. The tools and models change constantly; the loop should keep getting better.
I don't optimize for writing code faster. I optimize for shortening the loop between intent, implementation, failure and learning.
| Principle | How I work |
|---|---|
| Explore before building | Read the system, reproduce the problem, understand constraints and existing patterns before changing code. |
| Scale planning to complexity | Explore → Scope → Plan → Build. Small changes stay lightweight; architectural changes earn a spec, explicit decisions and a deeper implementation plan. |
| Engineer context | AGENTS.md as a portable entry point, with architecture docs, specs, decisions, scoped instructions and reusable skills as deeper sources of truth. Tool-specific context files are adapters, not the system of record. |
| Use agents as a system | Mix interactive and autonomous coding agents, parallelize independent work, and compare approaches when uncertainty is high. |
| Verify behavior, not intent | Typecheck, unit/integration tests, E2E, browser tests and agent evals where they actually reduce uncertainty. |
| Review adversarially | Diff review, AI review, human review and failure-oriented checks before shipping meaningful changes. |
| Close the loop | Production failure → root cause → test/eval → architecture or context update. |
┌──── CONTEXT ────┐
│ ↓
INTENT → EXPLORE → SCOPE → PLAN → BUILD → VERIFY → REVIEW → SHIP
↑ │ │ │
│ └── EVALS ─┘ │
│ │
└────────────── LEARN FROM REALITY ──────────┘
Process scales with complexity. A tiny fix should not need the same ceremony as a new subsystem. Specs, deeper research, explicit ADRs and parallel agents enter the loop when the problem earns them.
I switch environments depending on the problem and keep testing new ones rather than standardizing too early.
Coding environments / agents
Conductor · Cursor · Claude Code · Codex · Orca
Models
I regularly compare model families rather than building around a single provider — including Claude, GPT / Codex, and Gemini — and route work based on the task, latency, reliability and how well the model handles the surrounding context.
Supporting tools
Obsidian · Playwright · Greptile · architecture docs · ADRs · reusable skills · isolated worktrees when useful
No tool loyalty. No model loyalty. Keep what improves the loop; replace what doesn't.
When I say vanilla, I mean the baseline: the underlying LLM without the extra system around it — no custom retrieval, no tools, no skills, no orchestration layer. I use that baseline to understand whether the surrounding architecture is actually adding value.
The tools will change. The system shouldn't depend on any one of them.
Founder · Voice AI · Agents · Learning · Evals · Context · Automation · Developer tools
TypeScript · Python · Node.js · PostgreSQL · Docker
Tool Calling · RAG · Voice AI · LLM Evals · Agent Systems