Saltar al contenido principal
Ender Puentes
Abierto a nuevos roles full-time
Buenos Aires, Argentina

Construyo ideasen producción.

Diez años llevando producto a producción, con agentes de IA como equipo.

Problemas reales, decisiones concretas

Cada caso cuenta qué pasó, qué decidí y qué cambió después.

Estandarizar el Desarrollo en una Era de Código Generado por IA

Cuando la IA le dio a cada desarrollador control total sobre el código, perdimos los límites que mantenían consistencia entre proyectos. Construí starters con guardrails automáticos, hechos propios por todo el equipo.

ImpactoLos proyectos nuevos arrancan con las mismas reglas, y todo el equipo adoptó los starters

Un orquestador de workflows para push y email

Construí un orquestador centralizado que envía push y email a través de los proveedores que conecta cada equipo, y gran parte de la plataforma a su alrededor. La decisión central fue ejecutar cada nodo cuando le toca, porque los datos del suscriptor cambian mientras un workflow espera.

ImpactoUn solo orquestador envía push y email, con los datos más recientes de cada suscriptor

Diseñar un proceso a prueba de un product owner que no podía sostenerlo

Cuando quien cubría temporalmente el puesto de product owner del cliente no podía gestionar los requerimientos, no intentamos arreglar a la persona, rediseñamos el proceso.

ImpactoEl proyecto se entregó a tiempo y sin atrasos de contrato, con un proceso que no dependía de un solo rol

Diseñar una transición segura entre dos equipos de desarrollo

Un cliente quiso asumir el mantenimiento de un producto que desarrollábamos. Diseñé un handoff por niveles de riesgo para que dos equipos avanzaran en paralelo sin cuello de botella.

ImpactoDos equipos trabajan en paralelo sobre el mismo producto, sin esperarse entre sí

Estandarizar el Desarrollo en una Era de Código Generado por IA

Cuando la IA le dio a cada desarrollador control total sobre el código, perdimos los límites que mantenían consistencia entre proyectos. Construí starters con guardrails automáticos, hechos propios por todo el equipo.

ImpactoLos proyectos nuevos arrancan con las mismas reglas, y todo el equipo adoptó los starters

Un orquestador de workflows para push y email

Construí un orquestador centralizado que envía push y email a través de los proveedores que conecta cada equipo, y gran parte de la plataforma a su alrededor. La decisión central fue ejecutar cada nodo cuando le toca, porque los datos del suscriptor cambian mientras un workflow espera.

ImpactoUn solo orquestador envía push y email, con los datos más recientes de cada suscriptor

Diseñar un proceso a prueba de un product owner que no podía sostenerlo

Cuando quien cubría temporalmente el puesto de product owner del cliente no podía gestionar los requerimientos, no intentamos arreglar a la persona, rediseñamos el proceso.

ImpactoEl proyecto se entregó a tiempo y sin atrasos de contrato, con un proceso que no dependía de un solo rol

Diseñar una transición segura entre dos equipos de desarrollo

Un cliente quiso asumir el mantenimiento de un producto que desarrollábamos. Diseñé un handoff por niveles de riesgo para que dos equipos avanzaran en paralelo sin cuello de botella.

ImpactoDos equipos trabajan en paralelo sobre el mismo producto, sin esperarse entre sí

No delego el pensamiento. Delego la implementación

Trabajo con agentes en dos modos. Por defecto hago pair programming con Claude Code, en pasos cortos y con cada diff revisado por mí. Cuando el trabajo crece, paso a spec-driven development, con el plan escrito antes de cualquier código. Yo decido, los agentes ejecutan.

Un paso, un diff, un commit

El modo por defecto. El agente propone un cambio corto, yo leo el diff y nada se commitea sin mi ok.

  1. read (code graph): lee el código y me cuenta qué encontró antes de tocar nada
  2. pair (endev-pair): el modo por defecto, un paso corto a la vez. Reviso cada diff y apruebo cada commit
  3. plan (grill-me · planner + critic): cuando el trabajo supera al pair paso a SDD y el plan se cuestiona antes de escribir código
  4. execute (frontend · backend · mobile): los agentes especialistas implementan por olas, cada uno en su área
  5. review (tests + auditor): primero typecheck, lint y tests, luego un auditor revisa contra el plan. Corrijo o acepto, sin límite de rondas
  6. deliver (endev-deliver): cuando acepto, ordena los commits, hace push y abre el PR
  7. design: brief de diseño y tokens
  8. seo: metadata, JSON-LD y llms.txt
  9. docs: comentarios de doc y documentación
  10. qa: tests de uniones y a11y

Notas desde producción

Incidentes reales, decisiones de arquitectura, opiniones sobre IA y alguna reflexión sobre cómo trabajamos. Las escribo cuando algo se rompe, o cuando algo no me cuadra.

Ingeniería de producto4 min

Nadie se compromete con un rumbo que no entiende Leer nota

Una empresa puede cambiar de modelo de negocio, de sitio y de equipo en pocos meses. Lo que no puede es esperar compromiso de gente que no sabe hacia dónde va. Creo que la cultura es lo que deja girar sin perder a nadie, y que funciona en dos direcciones: alguien la tiene que explicar y alguien la tiene que querer.

Ingeniería de producto5 min

Una tarde con Claude no es una estimación Leer nota

CEOs y directivos están usando Claude para probar por fin las ideas que llevaban años guardando. Funcionan en una tarde, y esa tarde se vuelve la vara con la que miden al equipo: tiempos, mantenimiento, el trabajo que no se ve. Cuando la estimación honesta empieza a sonar a lentitud, el problema ya no es técnico.

Arquitectura de software7 min

La API del tercero no es tu modelo: adapters con Zod Leer nota

Cuando una API te suelta f_title y userid, TypeScript no se queja si lo copias. Al otro día el listado ya habla como ellos. Yo lo traduzco en el server con Zod: entra f_title, sale title, y a las pantallas les llega el objeto que sí quiero manejar.

Ingeniería de IA4 min

El equipo es la nueva ventana de contexto Leer nota

La IA hace más rápido al developer individual, pero no necesariamente al equipo. Diez developers con las mismas herramientas terminan con diez formas distintas de trabajar, y esa fricción se paga a nivel de equipo. La respuesta no es uniformar a las personas, es una base común de reglas, skills y criterios de review.

Ingeniería de IA5 min

Cuando el contexto empieza a jugar en contra Leer nota

Una hora de Grill.me sobre un sistema de permisos. Dejé al agente trabajar y volví a una implementación a medias: el contexto de esa conversación se había hinchado y el plan original ya no cabía. Lo bajé a un archivo por fases, una conversación nueva por fase, y ahí sí cerró.

Ingeniería de producto4 min

Nadie se compromete con un rumbo que no entiende Leer nota

Una empresa puede cambiar de modelo de negocio, de sitio y de equipo en pocos meses. Lo que no puede es esperar compromiso de gente que no sabe hacia dónde va. Creo que la cultura es lo que deja girar sin perder a nadie, y que funciona en dos direcciones: alguien la tiene que explicar y alguien la tiene que querer.

Ingeniería de producto5 min

Una tarde con Claude no es una estimación Leer nota

CEOs y directivos están usando Claude para probar por fin las ideas que llevaban años guardando. Funcionan en una tarde, y esa tarde se vuelve la vara con la que miden al equipo: tiempos, mantenimiento, el trabajo que no se ve. Cuando la estimación honesta empieza a sonar a lentitud, el problema ya no es técnico.

Arquitectura de software7 min

La API del tercero no es tu modelo: adapters con Zod Leer nota

Cuando una API te suelta f_title y userid, TypeScript no se queja si lo copias. Al otro día el listado ya habla como ellos. Yo lo traduzco en el server con Zod: entra f_title, sale title, y a las pantallas les llega el objeto que sí quiero manejar.

Ingeniería de IA4 min

El equipo es la nueva ventana de contexto Leer nota

La IA hace más rápido al developer individual, pero no necesariamente al equipo. Diez developers con las mismas herramientas terminan con diez formas distintas de trabajar, y esa fricción se paga a nivel de equipo. La respuesta no es uniformar a las personas, es una base común de reglas, skills y criterios de review.

Ingeniería de IA5 min

Cuando el contexto empieza a jugar en contra Leer nota

Una hora de Grill.me sobre un sistema de permisos. Dejé al agente trabajar y volví a una implementación a medias: el contexto de esa conversación se había hinchado y el plan original ya no cabía. Lo bajé a un archivo por fases, una conversación nueva por fase, y ahí sí cerró.

El stack con el que entrego

Cada herramienta viene con el patrón que la sostiene. Gira el dial para ver ambos.

markdown

# spec.md
## Requirements
## Acceptance criteria
// the agent implements against this, not vibes

10 años de trayectoria

De frontend freelance a liderar producto, plataforma e IA aplicada. Cada paso dejó algo que sigo usando.

2026

Rol senior con foco en producto

Me interesa un rol donde el criterio técnico se traduzca en producto. Quiero construir cerca del cliente, tomar decisiones de arquitectura con contexto real y hacer crecer al equipo. Ya he liderado productos y equipos, y quiero que esa experiencia tenga más alcance.

  • Product Engineer
  • Forward Deployed Engineer
  • Software Architect
  • Mentoría
Endev
Sobre mí

Cómo construyo y por qué

Si llegaste hasta aquí, probablemente quieras saber un poco más de mí. Llevo muchos años construyendo software y todavía me importa lo mismo que al principio, ver una idea convertirse en algo que realmente funciona.

El código es solo una parte del trabajo. A veces toca pensar producto, otras arquitectura, revisar un deploy o quedarme hasta entender por qué algo que funcionaba ayer dejó de funcionar hoy. Así es producción. Tiene personalidad propia.

También disfruto ayudar a otros a crecer. Un buen code review no solo dice qué está mal, deja a la otra persona entendiendo algo que antes no entendía.

Me interesa entender el problema, discutir las decisiones cuando hace falta y encontrar la forma más simple y sólida de llevarlo a producción.

Trabajo principalmente con TypeScript y Node.js, y sigo de cerca lo que pasa con IA y agentes porque el trabajo está cambiando rápido. Adopto herramientas nuevas cuando realmente mejoran el producto, el equipo o la forma en que trabajamos.

Estoy terminando Ingeniería de Sistemas, aunque mi carrera no esperó al título. La mayor parte de lo que sé lo aprendí construyendo y equivocándome en sistemas reales.

  • Frontend y backend
  • Arquitectura y estándares
  • Mentoría
  • Next.js
  • Ingeniería asistida por IA

Hablemos

Abierto a roles full-time como Senior Full Stack Developer, con foco en producto y arquitectura. Si estás reclutando o armando un equipo, escríbeme por el formulario o al email de esta página. Trabajo desde Buenos Aires (GMT-3) y respondo en español o inglés.

Nombre

Email

Mensaje

--:--

buenos airesEn la oficina, la respuesta puede tardar unas horas
  • Disponible
  • En la oficina
  • Desconectado
Currículum