Daniel Estévez: my story, how I work, and why I built Vinaya

I use AI to multiply my output without giving up my judgment. Agents build faster; I stay the one who decides what "correct" means. I don't ship code I don't understand just because an agent wrote it.

Who I am

I've been building software for eighteen years, with frontend at the centre since 2016. I started as a full-stack engineer, but the UI side won me over and never let go. I've spent over a decade turning designs and wireframes into real interfaces, and I notice details everywhere. I can't stop until something looks right, and I know when it's right enough to ship.

I love frontend, and I always have. Over the last few years I've gone very deep into building with AI, but the front is still my heart and the part that stays fun. Even for my own harness, I couldn't stop myself from building a beautiful frontend.

I'm an EU (Spanish) citizen based in Thailand (GMT+7), and I've worked remotely since 2016.

How I started with AI

• Late 2022: ChatGPT, outside the IDE. I used it to move faster while keeping my own judgment, never to outsource the thinking.
• Early 2024 to March 2026, at Game7: I brought AI into the IDE, on a production team, for two years.
• Since April 2026: full time on my own work, all-in with agents. I've been building Vinaya since May 2026.

What I learned the hard way

At Game7 I reached a very good way of working. I spent hours pair-programming with AI and got exactly the code, architecture and technical decisions I would have made myself, only faster. It was amazing. It was also dangerous.

• There were always pieces I quietly stopped owning. I'd find dependencies I would never have installed, and pull requests too big to really review.
• Parallel agents pile up tech debt. The committed code slowly drifts into a mess.
• The real danger is subtler than bad code: you lose sight of your own codebase. Agents make hundreds of decisions under the hood, and the more you run in parallel, the more of them slip past you.
• The most critical part: the team was losing the learning too. When the agent makes the decisions, nobody on the team learns why. Knowledge that used to spread through reviews and pairing stopped spreading.

I also learned that context is everything. So I learned to engineer it: structured specs and skills, careful context, controlled token spend, so the agent builds from the real shape of the system and not from a guess.

That's why I started building Vinaya.

Vinaya in thirty seconds

Agents write code fast, but they fail all the time, and on a team they quietly pile up code nobody understands. Vinaya fixes that. It runs the whole engineering workflow as a pipeline of AI agents a human can trust: a planner writes the task, a developer agent builds it, two independent reviewer agents judge it, and deterministic checks gate every step. Nothing is taken on an agent's word. Rules are code, and every run, check and verdict is recorded, so the system can be measured and improved. I ship real features with it every day.

Vinaya is the Pāli word for the Buddhist monastic code: the discipline that lets a community work together. Here it's the discipline that lets a team of agents work together.

How Vinaya came together

1. The problem. Engineers coding fast with AI end up with huge pull requests, growing tech debt, and code nobody owns.
2. My answer. I didn't stop using agents. I put the whole workflow into a pipeline of them. Planning, building, reviewing and closing a task each became a role with a contract, and code checks every hand-off.
3. The Log. Once agents run the pipeline, you need to see exactly what happened. So every act is recorded: every run, check, verdict and pause.
4. Closing the loop. The Log is what makes the rest possible: watching work live in Studio, looking back at each task in a retrospective, and measuring the agents properly with evals. The system's own record tells me what to fix next.

Why it's hard. Agents fail constantly. They stall, misreport, claim they're done when they aren't, and give a confident 98% on work a reviewer then rejects. Making a pipeline of them deliver reliably is engineering, not prompting. Vinaya's answer is the same everywhere: an agent never decides a fact. Code computes it, checks enforce it, the Log records it, and a human approves what matters. I'm proud of how well it works.

What it does, in plain facts:

• Claude Code or Codex develops. Deterministic checks run locally and in CI and give the same verdict in both places. Two independent reviewer agents judge every change.
• Status is never stored, only derived from what actually happened in the repository, so unfinished work can't pass as finished.
• Three enforcement rings: before a commit, in CI, and as an audit after merge, all running the same checks.
• A check may only fail a pull request that could cause or fix the problem it reports.
• Every run, check and review is recorded. My public development log is built from those records: zerion.attalabs.dev/dev-stats.

My role. I ship product features through Vinaya. I keep the specs, the docs and the code aligned, and I make sure the workflow delivers what it's supposed to. When an agent fails, I fix the system, not just the output.

What I'm building now

• Evals with Harbor. Harbor is the harness behind Terminal-Bench. I use it to run my real agent roles on real tasks from Vinaya's own history, in isolated containers, graded against hidden tests. The setup works and the first practice runs are done; scored runs come next.
• Atta Engine, which I also built. In one line: a YAML compiler that runs LangGraph and executes my own drivers. I describe the workflow as a YAML flow: which steps, in what order, where it loops back, and what runs in parallel. The Engine compiles it and runs it on LangGraph, which gives me checkpoints, pause and resume, and stop conditions. At each step it calls my code: an agent role with exactly its own tools and permissions, or a deterministic check. It lets me follow proper agent architecture (one controller, isolated agents, tools enforced in code, clear stop conditions) instead of hand-writing all of it. Vinaya now runs on two backends: its standalone driver and Atta Engine.

How I work

• I direct agents; I don't defer to them. I set the architecture, they build, and I keep judgment where it matters.
• Every line shipped is understood by the human who owns it.
• A spec is the front half of the work: an agent executes exactly as well as the brief it's given.
• Verdicts come from code, not from prompt instructions. If a rule matters, a check enforces it.
• One concrete, verifiable fact beats three paragraphs of argument. I link the code so you can read it instead of trusting me.
• Short, direct, no fluff.

To be clear

• Vinaya and my other AttaLabs tools are built and deployed, but they're my own projects with no paying customers yet. My production experience comes from Game7, Elixir and the roles before them.
• Scored eval results are next: the Harbor setup runs and practice runs are done, but I don't publish numbers yet.

Find me

• Vinaya: vinaya.attalabs.dev
• A real result of Vinaya: zerion.attalabs.dev (Onchain Rewind, a weekend experiment built entirely through Vinaya) and its stats page, zerion.attalabs.dev/dev-stats
• Code: github.com/atta-labs/attalabs
• Happy to work as a contractor or through an employer of record.