SaaS de facturación AI-native

Escala

El tamaño

Es un producto grande, y de eso va este caso: una sola persona dirigiendo agentes lo cubrió entero, en todas las capas.

• Apps

  El producto, una consola de administración, una web de aterrizaje y la API, además de procesos en segundo plano y una simulación de la administración tributaria.

• API

  Cientos de endpoints detrás de las aplicaciones web.

• Pantallas

  Producto, administración y web de aterrizaje. Cada parte es una aplicación completa con sus propios flujos.

• Base de datos

  Un esquema relacional grande en PostgreSQL.

• Seguridad a nivel de fila

  Cientos de políticas separan los datos de cada cliente.

• Trabajo en segundo plano

  Procesos y tareas programadas fuera del camino de las peticiones.

• Triggers

  Muchos protegen registros que nunca deben cambiar.

• Tests

  Decenas de miles, entre backend, frontend y end to end.

El trabajo detrás

Lo que de verdad costó

Claude escribió la mayor parte del código. Lo difícil era llegar a un código que yo estuviera dispuesto a fusionar, y esa parte era mía.

1. 01Muchas vueltas con Claude

   El trabajo solía necesitar varias vueltas. Rechazaba lo que parecía correcto pero no lo era, y seguía hasta que llegaba al listón. Que compile es donde empieza la revisión.

2. 02Diseñar el pipeline como un producto

   Diseñé el montaje multiagente y multisesión y lo fui mejorando a medida que fallaba de formas nuevas: cómo se reparte el trabajo, cómo los agentes no se pisan y qué tiene que pasar antes de fusionar nada.

3. 03Conocer el dominio

   La facturación con cumplimiento fiscal tiene reglas que un agente no puede adivinar. Entenderlas y decidir cómo las trata el producto era mi trabajo. El subagente de cumplimiento revisa. No decide.

4. 04Decidir la arquitectura

   Aislamiento entre clientes, registros que no cambian, cómo se redondea el dinero, cómo llega cada versión a staging. Esas decisiones las tomé yo, y los agentes trabajaban dentro de ellas.

5. 05Ser el listón de calidad

   Nada se fusionaba sin mi revisión. Todas las pull requests pasaban por mí, de una en una.

Quién hace qué

Un desarrollador, un equipo de agentes Claude

Yo marcaba la dirección y tomaba cada decisión de producto. Varias sesiones de Claude escribían la mayor parte del código en paralelo, y nada llegaba a la rama principal sin pasar los controles y mi revisión.

1. Reglas y memoriaLo que los agentes deben saber y lo que nunca deben hacer, versionado con el código.
2. SkillsSkills para los trabajos que se repiten.
3. El bucle de orquestaciónClaude mantiene el trabajo en marcha y contrasta el plan con lo que de verdad ha pasado.
4. ControlesComprobaciones ejecutables. Una comprobación solo cuenta cuando se ha visto en rojo, y cada arreglo debe traer un test que falle en main.

Pruebas

Cómo medí si funcionaba

Los agentes producen mucho código muy rápido, así que la pregunta que me hacía siempre era cómo saber si era correcto. La respuesta acabó en cuatro reglas.

1. 1

   Tres pruebas por control

   Una comprobación no cuenta hasta que supera tres pruebas. Una de ellas es romper el código a propósito y ver cómo se pone en rojo.

2. 2

   Mutación antes de fiarse del verde

   Una batería que pasa dice poco hasta que la mutación demuestra que puede fallar.

3. 3

   Predicciones antes de medir

   Escribo lo que espero antes de medir, para que el resultado pueda llevarme la contraria.

4. 4

   Un test de regresión por arreglo

   Tiene que fallar contra main. Si pasa con el código roto, no demuestra el arreglo.

El pipeline, antes y después de pasar a un flujo multiagente orquestado

Antes

una muestra de pull requests de una ventana anterior al cambio

Después

todas las pull requests fusionadas en una ventana de la misma duración después

Después de pasar a un flujo multiagente orquestado, se fusionaron más pull requests y las más grandes bajaron un 36 %, mientras que la mediana del tiempo hasta el merge subió porque los merges se hacían de uno en uno. Esa fila está porque es verdad.

La comparación es observacional, no controlada. Las dos ventanas cuentan poblaciones distintas, cambiaron otras cosas a la vez y la segunda ventana estuvo dominada por una racha de arreglos fusionados uno detrás de otro.

No doy cifras de cobertura de tests. No la he medido, y he visto un control en verde que no probaba nada.

Ritmo

El ritmo

Cómo avanzaba el trabajo.

• En paralelo

  Varias sesiones de Claude a la vez, cada una en su git worktree y con su propia tarea.

• Un solo revisor

  Todas las pull requests pasaban por mí, y las fusionaba de una en una.

• Constante

  Los merges llegaban con frecuencia. El trabajo avanzaba pull request a pull request.

Herramientas

Stack

• Backend

  • Python
  • FastAPI
  • Pydantic v2 (estricto)
  • SQLAlchemy asíncrono
  • Dinero en decimal

• Frontend

  • TypeScript (estricto)
  • React
  • Vite
  • Tailwind
  • shadcn/ui
  • TanStack
  • Zustand
  • Zod

• Datos

  • PostgreSQL
  • Aislamiento entre clientes en la base de datos
  • Registros inmutables

• Infraestructura

  • Terraform
  • Kubernetes (K3s)
  • CDN y DNS
  • Red privada (VPN)
  • Paneles de métricas, logs y alertas

• Entrega

  • Pipelines de CI
  • Runners propios
  • Staging con rollback automático
  • Workflow de promoción

• Testing

  • pytest
  • Tests con base de datos real
  • pgTAP
  • Vitest
  • Playwright
  • mutmut

• Pagos

  • Pagos con tarjeta y suscripciones

• IA en el producto

  • Captura de documentos con OCR y un LLM

• Herramientas de IA

  • Claude Code: orquestador, escritores, revisor, cumplimiento, QA