Alí Padrón

Method

How I work

I build with AI agents as part of the method, not as a shortcut around it. The loop is the same one I use at work and on my own projects: grill the idea, write the spec, cut it into tickets, run independent tickets in parallel, and review everything that ships. Agents write a large part of the code. I own the decisions, the review and the release.

The loop

  1. Grilling

    I start with an interview, not a prompt: one question at a time until the problem, the constraints and the edge cases are on the table. The output is a decision tree I can defend, not a wish list.

  2. Spec

    The answers become a short written spec: what we are building, what we are not, the decisions already taken and the risks still open. A vague spec produces confident, wrong code, so this is where I spend the extra hour.

  3. Tickets

    I cut the spec into vertical slices that each ship something usable. Every ticket carries acceptance criteria and names what blocks it, so the order is a graph rather than a guess.

  4. Parallel agents

    Independent tickets run at the same time, each in its own worktree and session with the same conventions and context. Agents do not merge, push to protected branches or touch production credentials; those stay with me.

  5. Review gates

    Nothing lands because an agent said it was done. Typecheck, lint and tests run in CI, a security scan and an AI first pass run on the merge request, and I read the diff before it ships. Releases have their own gate.

What I delegate

  • Implementation once the slice is specified: components, endpoints, migrations and tests.
  • The mechanical work: renames, dependency upgrades, wiring, boilerplate and test scaffolding.
  • A first pass at code review and at listing the obvious failure modes.
  • Research with a written result: comparing two libraries, mapping an unfamiliar codebase, drafting the ticket breakdown.
  • Documentation and ADRs from decisions we have already made.

What I keep

  • The spec, the architecture and the data model. Agents propose; I decide.
  • Anything that touches payments, authentication, personal data or production configuration.
  • Database migrations and anything that cannot be rolled back cleanly.
  • The final read of every diff that ships, and the release itself.
  • The conversation with product and with the client. Context that only lives in a meeting is context an agent does not have.

Guardrails

A faster loop is only useful if it is safe to run many times a day. These are the limits I set before an agent starts:

  • A short AGENTS.md and convention docs per repository, so an agent gets the same rules a new developer would.
  • Read-only production access, with every command approved, and no permission to merge or push to protected branches.
  • One ticket per worktree, with the spec and the acceptance criteria in the prompt.
  • A budget cap per run and per repository, so parallel agents do not become a surprise invoice.
  • A human at every irreversible step: schema changes, secrets, releases and customer data.

Where it breaks

This method is fast at well-bounded work and slower at the start on purpose. It does not rescue a vague product decision, and it does not replace debugging a production incident or sitting with someone to understand what they actually need. It also raises the cost of a bad spec: an agent will implement the wrong thing thoroughly, with tests. The review gate exists to catch that, and it is the part I refuse to automate away.